cesagbibliotheque.cesag.sn/gestion/documents_numeriques/m0123...l’audit est de réduire en grande...

Présentée par : Dirigé par :

Avril 2013

Centre Africain d’Etudes Supérieures en Gestion

Mémoire de fin d’études

THEME

ÉVALUATION DE LA QUALITE D'UNE MISSION D'AUDIT INFORMATIQUE: CAS DU CABINET

QUALISYS CONSULTING

Mr. PAUL JUNIOR OPONGA M. Alain SAWADOGO

Professeur associé au CESAG

Promotion 5

(2010 2012)

Institut Supérieur de Comptabilité,

de Banque et de Finance

(ISCBF)

Master Professionnel en Audit

et Contrôle de gestion

(MPACG)

CESAG - BIBLIOTHEQUE

Évaluation de la qualité d'une mission d'audit informatique: Cas du cabinet Qualisys Consulting

OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page i

DEDICACES

Ce mémoire est dédié :

o à mon Dieu tout puissant, pour la force qu’il m’a procuré durant toute ma

formation;

o à mes parents M. et Mme OPONGA;

o à mes frères et sœurs ;

o à Raoul OKO ;

o à mon amie Nysse Andreane pour son affection ;

o à tous ceux qui, de près ou de loin, ont contribué à sa réalisation. CESAG - BIBLIOTHEQUE


OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page ii

REMERCIEMENTS

Je ne saurais commencer ce mémoire sans témoigner ma gratitude à mon directeur de

mémoire, Monsieur SAWADOGO Alain, qui a bien voulu m’encadrer, et qui a fait preuve

de disponibilité.

Ma gratitude va également à l’endroit de Monsieur YAZI Moussa, Directeur de l’ISCBF,

et de Monsieur LOKOSSOU Hugues pour son soutien.

Mes remerciements vont à l’endroit du personnel du Cabinet Qualisys Consulting. Je

voudrais spécialement citer le département technique, le chef de ce département avec qui

j’ai eu le plus à travailler.

Mes remerciements vont à l’endroit du corps professoral et de l’administration du CESAG,

qui contribue, tous, au professionnalisme des étudiants en Afrique. Je voudrais remercier

aussi tous mes amis, en particulier ITOUA Maellord et WABERI IGAL Mahmoud,

compagnon de promotion, pour son aide. Paix à son âme.



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page iii

LISTE DES SIGLES ET ABREVIATIONS

AFAI : Association Française de l'Audit et du Conseil Informatique

CISA: Certified Information System Auditor

COBIT: Control objectives for information and related technology

DI : Direction Informatique

FRAP : Feuille de Révélation et d'Analyse de Problème

ISA 310 : Norme de connaissance générale de l’entité et de son secteur d’activité

ISACA: Informations System Audit and Control Association

ISO : Organisation Internationale de Normalisation

MEF : Ministère de l’Economie et des Finances

MPACG : Master Professionnel en Audit et Contrôle de Gestion

QC : Qualisys Consulting

SI : Système d’Information

SMQ : Système de Management de la Qualité



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page iv

LISTE DES ANNEXES

Annexe 1 : Organigramme du Cabinet ................................................................................ 77

Annexe 2 : Cartographie des Risques .................................................................................. 78

Annexe 3 : Exemple d’échelle d’évaluation des risques informatiques .............................. 82

Annexe 4 : Plan de travail d’audit ....................................................................................... 83



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page v

TABLE DES MATIERES

DEDICACES .......................................................................................................................... i

REMERCIEMENTS ............................................................................................................. ii

LISTE DES SIGLES ET ABREVIATIONS ........................................................................ iii

LISTE DES ANNEXES ....................................................................................................... iv

TABLE DES MATIERES ..................................................................................................... v

INTRODUCTION GENERALE ........................................................................................... 1

PREMIERE PARTIE : CADRE THEORIQUE .................................................................... 6

CHAPITRE I : CONDUITE D’UNE MISSION D’AUDIT CONTRACTUEL ............... 8

1.1. Définition et objectif d’une mission d’Audit informatique ............................... 8

1.2. Les concepts de base de l'audit informatique .................................................... 9

1.3. Différents types d'audit informatique. ............................................................. 12

1.3.1. Audit de l’organisation de la fonction informatique .................................. 13

1.3.2. Audit des études informatiques .................................................................. 14

1.3.3. Audit de l'exploitation ................................................................................ 15

1.3.4. Audit des projets informatiques ................................................................. 16

1.3.5. Audit des applications opérationnelles ...................................................... 17

1.3.6. Audit de la sécurité informatique ............................................................... 17

1.4. Code déontologique ......................................................................................... 18

1.4.1. Principes fondamentaux ............................................................................. 18

1.4.2. Règles de conduite ..................................................................................... 18

1.5. Normes de l’audit ............................................................................................ 19

1.5.1. Normes de qualification ............................................................................. 20

1.5.2. Normes de fonctionnement ........................................................................ 20

1.5.2.1. La lettre de mission .............................................................................. 20

1.5.2.2. Planification ......................................................................................... 21

1.5.2.3. Réunion d'ouverture ............................................................................. 21

1.5.2.4. Réalisation du travail d’audit ............................................................... 22

1.5.2.5. Le compte rendu final .......................................................................... 23

1.5.2.6. Rapport ................................................................................................. 23

1.5.2.7. Activités de suivi ................................................................................. 25

CHAPITRE 2 : QUALITE D’UNE MISSION D’AUDIT INFORMATIQUE. ............. 27

2.1. Les caractéristiques de la qualité ..................................................................... 27



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page vi

2.2. Objectifs et démarche d’évaluation de la qualité : .......................................... 27

2.2.1. Objectifs d’une évaluation ......................................................................... 27

2.2.2. Démarche d’évaluation de la qualité ......................................................... 28

2.3. Indicateurs de la qualité d’une mission d’audit informatique: ........................ 29

2.3.1. Planification ............................................................................................... 29

2.3.1.1. Objectifs de l’évaluation des risques informatiques ............................ 30

2.3.1.2. Identification des risques informatiques .............................................. 31

2.3.1.3. Principes d’évaluation des risques de l’entreprise .............................. 32

2.3.1.4. Hiérarchisation des risques .................................................................. 32

2.3.1.5. Traitement des risques ......................................................................... 33

2.3.2. Réalisation du travail d’audit ..................................................................... 34

2.3.2.1. Sécurité informatique ........................................................................... 34

2.3.2.2. Sécurité des fonctions applicatives ...................................................... 36

2.3.2.3. Les ressources humaines informatiques............................................... 36

2.3.2.4. Maintenance ......................................................................................... 37

2.3.2.5. Gestion des incidents ........................................................................... 38

2.3.2.6. Efficacité et efficience de la fonction informatique ............................. 38

2.3.2.7. Help desk informatique ........................................................................ 38

2.3.2.8. Contrôle d'activité du cabinet .............................................................. 39

2.3.2.9. Contrôle de la performance du cabinet ................................................ 39

2.3.3. Rapport ....................................................................................................... 39

2.3.4. Activités de suivi ....................................................................................... 40

2.3.5. Les déterminants de la qualité de l’audit informatique .............................. 40

2.4. La présentation, l’analyse des résultats et les recommandations..................... 41

2.4.1. La présentation des résultats ...................................................................... 41

2.4.2. L’analyse des résultats ............................................................................... 41

2.4.3. Les recommandations : .............................................................................. 42

CHAPITRE 3 : APPROCHE METHODOLOGIQUE .................................................... 43

3.1. Modèle d’analyse ............................................................................................. 43

3.2. Méthode de collectes de données d’une mission d’audit informatique ........... 45

3.2.1. L’entretien d’audit ..................................................................................... 45

3.2.2. L’observation directe et l’observation physique ........................................ 45

3.2.3. Le questionnaire ......................................................................................... 45

3.2.4. Les grilles d'analyse de contrôle interne .................................................... 46



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page vii

3.2.5. La documentation : .................................................................................... 46

3.2.6. La méthode analytique : ............................................................................. 46

DEUXIEME PARTIE : CADRE PRATIQUE .................................................................... 48

CHAPITRE 4 : PRESENTATION DU CABINET QUALISYS CONSULTING ......... 50

4.1. Historique du Cabinet ...................................................................................... 50

4.2. Mission et Objectifs ......................................................................................... 51

4.2.1. Mission ....................................................................................................... 51

4.2.2. Objectifs ..................................................................................................... 51

4.3. Organisation du cabinet ................................................................................... 51

4.3.1. Structure opérationnelle ............................................................................. 52

4.3.2. Le département technique .......................................................................... 53

4.3.3. Les différents secteurs d’activités ou le cabinet intervient ........................ 53

4.3.4. Différents types d’audit réalisé par le cabinet............................................ 54

CHAPITRE 5 : EVALUATION DE LA QUALITE DE LA MISSION D’AUDIT

INFORMATIQUE. .......................................................................................................... 55

5.1. Evaluation de la planification de la mission .................................................... 56

5.1.1. Aspect positif de l’évaluation .................................................................... 58

5.1.2. Aspect négatif de l’évaluation ................................................................... 58

5.2. Evaluation de la réunion d'ouverture ............................................................... 59



5.3. Evaluation de la réalisation du travail d’audit ................................................. 59

5.3.1. Aspect positif de l’évaluation : .................................................................. 65


5.4. Evaluation du compte rendu final .................................................................... 66



5.5. Evaluation du rapport d’audit .......................................................................... 67

5.5.1. Aspect positif de l’évaluation : .................................................................. 67

5.5.2. Aspect négatif de l’évaluation : ................................................................. 68

5.6. Activités de suivi ............................................................................................. 68

CHAPITRE 6 : PRESENTATION, ANALYSE DES RESULTATS ET

RECOMMANDATIONS. ............................................................................................... 69

6.1. L’analyse des résultats ..................................................................................... 69



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page viii

6.2. Recommandations ........................................................................................... 70

6.2.1. Recommandations relatives à la planification de l’audit ........................... 70

6.2.2. Recommandations relatives au travail d’audit ........................................... 71

6.2.3. Recommandations relatives au fonctionnement du cabinet qualisys ......... 71

6.2.4. Mise en œuvre des recommandations ........................................................ 72

CONCLUSION GENERALE ............................................................................................. 74

ANNEXES .......................................................................................................................... 76

BIBLIOGRAPHIE .............................................................................................................. 85


INTRODUCTION GENERALE



OPONGA Paul Junior 5e Promotion MPACG ISCBF/ CESAG Page 2

D’après FUSARO & MILLER (2003), dans leur ouvrage Enron1, les vraies raisons de la

chute, « les récents scandales générés par des rapports d’audit biaisés ont bouleversé

l’évaluation de la qualité de l’audit. Ils ont démontré l’incapacité des approches classiques

dévaluation à appréhender la qualité d’une mission d’audit ».

Pour ANGOT, (2004 :20), « en tant que mécanisme de gouvernance, le rôle essentiel de

l’audit est de réduire en grande partie l’asymétrie d’information entre gestionnaires et

actionnaires ou tiers contractants. Cependant l’appréciation ou la mesure de cette qualité

est problématique. Le résultat de la qualité d’audit n’étant pas directement ou

immédiatement visible, et le rapport d’audit est tellement standardisé dans son contenu et

dans sa formulation qu’il n’offre que peu de possibilité de différenciation ».

Pour WOOTEN (2003 : 15) « un échec d’audit n’est souvent connu que dans un contexte

de faillites largement médiatisé. Il est en effet difficile de connaître le nombre des audits de

mauvaise qualité qui passent inaperçus sans qu’ils soient rendus publics ».

De ANGELO (1981 : 20) par contre admet que « l’évaluation de la qualité d’audit repose

sur deux concepts de base : la compétence et l’indépendance de l’auditeur. Ces derniers,

sont soit perçus par le marché soit liés aux caractéristiques intrinsèques de ces deux

concepts ».

La qualité de l’audit constitue une garantie fondamentale de la vraisemblance des contrôles

et de la crédibilité des rapports divulgués par les auditeurs. Pour PRAT (2003 : 5), « le

second critère fait référence à l’objectivité de l’auditeur et surtout à son indépendance par

rapport aux groupes de pressions ne souhaitant pas une certaine forme de jugement. D’une

façon générale, l’indépendance de l’auditeur externe peut être assurée par sa résistance aux

pressions exercées par son client et les autres partenaires de la firme le cas échéant ».

1 D’après WIKIPEDIA(2012), Enron fut l'une des plus grandes entreprises américaines par sa capitalisation boursière. Outre ses activités propres dans le gaz naturel, cette société texane avait monté un système de courtage par lequel elle achetait et revendait de l'électricité, notamment au réseau des distributeurs de courant de l'État de Californie. En décembre 2001, elle fit faillite en raison des pertes occasionnées par ses opérations spéculatives sur le marché de l'électricité, qui avaient été maquillées en bénéfices via des manipulations comptables. Cette faillite entraîna dans son sillage celle d'Arthur Andersen, qui auditait ses comptes.




Pour WOOTEN (2003), l’auditeur externe peut surévaluer la qualité de ses prestations en

induisant en erreur son client. L’auditeur peut recourir à de telles pratiques afin d’obtenir

un mandat (dans un marché de concurrence) ou pour justifier des honoraires plus élevés.

Le problème de la sélection adverse peut encore subsister pendant la mission d’audit.

L’auditeur peut induire en erreur son client sur la composition et la compétence de l’équipe

intervenante par rapport aux termes convenus lors de la signature du contrat. Pour éviter ce

désagrément aux audités, chaque mission doit faire l’objet d’une évaluation qualité afin de

savoir si les processus d’audit sont respectés.

« Un audit est de qualité lorsque l’auditeur est probe et intègre d’une part, et compétent sur

le plan technique et professionnel d’autre part. La qualité de l’audit dépend aussi de

certains indicateurs » (COLUMBA : 2008). Dans le cadre de notre étude nous avons retenu

les meilleurs pratiques d’une mission d’audit informatique comme indicateurs qualité. Ces

indicateurs seront évalués de façon pertinente. Puis nous analyserons les résultats afin de

savoir si cette mission est de qualité en vérifiant si elle répond aux normes d’audit

informatique. Ensuite nous formulerons les recommandations.

COLUMBA (2008), nous apprend que « l’audit de l’organisation de la fonction

informatique dans un cadre légal vise à s’assurer que les politiques et procédures de

sécurité définies par l’audité pour assurer le maintien en conditions opérationnelles d’une

application ou d’une partie du système d’information sont conformes au besoin de sécurité

de l’organisme audité, par rapport aux normes en vigueur ». C’est dans cette optique que le

Ministère de l’Economie et des finances, à commander un audit pour jauger l’organisation

de sa fonction informatique au sein de sa direction chargé de l’informatique.

Cependant les missions d’audit réalisées par le cabinet Qualisys Consulting mettent

souvent en lumière des lacunes quant :

o à l’importance des différents types d’indicateurs à évaluer ;

o au mauvais choix des outils d’audit informatique ;

o à la méthodologie d’audit adoptée.

De ce fait les conséquences sont nombreuses :

o ne pas effectuer un audit de qualité ;

o induire en erreur l’audité à travers un rapport d’audit mal fait.




Les causes de ces problèmes proviennent :

o d’une application partielle des méthodes et standards d’audit informatique en

vigueur ;

o ne pas mettre à jour de connaissances professionnelles des auditeurs en permanence.

Dans le souci de produire après chaque mission un audit de qualité pour les audités,

nous serons amenés à mettre en place un certain nombre de solutions pour palier à ces

problèmes :

o mise à jour en permanence des connaissances professionnelles ;

o choisir les bons outils d’audit pour chaque mission ;

o évaluer régulièrement la qualité de chaque mission d’audit.

En effet de toutes ces solution, la dernière mérite d’être retenue afin d’améliorer la qualité

du travail après chaque mission audit.

Ainsi notre souci, par rapport à cette étude est de savoir, quel est le niveau de qualité de la

mission d’audit contractuelle réalisé par le cabinet Qualisys Consulting au sein du

ministère de l’Economie et des finances du Sénégal ?

Nous essaierons de répondre à ces questions :

o quels sont les indicateurs de qualité d’une mission d’audit ?

o quels en sont les déterminants ?

o comment évaluer la qualité d’une mission d’audit?

Ainsi pour comprendre l’importance de la qualité d’une mission d’audit nous proposons de

traiter le thème suivant : évaluation de la qualité d’une mission d’audit informatique cas du

cabinet Qualisys Consulting.

Notre objectif ici est la description de la conduite, de la mission d’audit contractuel de

l’organisation de la fonction informatique réalisé par le cabinet Qualisys Consulting, de

déceler les dysfonctionnements lors de la mission. Puis de formuler les recommandations

pour améliorer la qualité des prochaines missions.

Les objectifs spécifiques sont :




o établir un référentiel d’audit ;

o de mettre en place une méthodologie d’évaluation la qualité de la mission ;

o analyser les résultats et formuler des recommandations.

Nous délimiterons notre champ d’étude sur la dernière mission d’audit informatique

effectué au ministère de l’Economie. Le ministère de l’Economie et des finances, conscient

de l’importance de la confidentialité, disponibilité, de l’intégrité et de la fiabilité de son

système informatique, compte jauger son niveau de productivité.

Ainsi, le projet d’audit doit couvrir tous les aspects de l’organisation de la fonction

informatique. En effet, son domaine d’application concerne tous les aspects techniques,

organisationnels, concourant à la sécurité et à la sûreté des systèmes d’information.

Cette étude aura un intérêt particulier pour :

o nous-mêmes, une première approche de la vie professionnelle et de mettre en

pratique nos acquis théoriques, ainsi que de parfaire nos connaissances dans le cadre

de notre formation ;

o les dirigeants du Cabinet Qualisys, cela pourrait leur permettre d’améliorer la

qualité de leurs missions audits ;

En dehors de l’introduction et de la conclusion, la réflexion, objet de cette étude se décline

en deux parties qui sont :

o la première partie intitulée le cadre théorique, qui comprend trois chapitres, sera

consacrée à la revue critique de littérature. Le premier chapitre décrira la conduite

d’une mission d’audit informatique, puis le second chapitre traitera de l’évaluation

de la qualité d’une mission d’audit informatique. Le chapitre III sera celui de

l’approche méthodologique;

o la deuxième partie intitulée cadre pratique qui comprend trois chapitres à savoir la

présentation du Cabinet Qualisys Consulting, le déroulement puis l’évaluation de la

qualité de la mission d’audit informatique au niveau du chapitre V, ensuite il y’aura

au chapitre VI, la présentation et l’analyse des résultats suivi des recommandations.


PREMIERE PARTIE : CADRE THEORIQUE




ANGOT (2004), affirme que « dans l’acceptation la plus courante, le terme audit

correspond aux concepts de contrôle, orientation et supervision. Le but des investigations

menées dans un cadre légal2 consiste à tirer une conclusion globale. Cette conclusion doit

permettre de se faire une idée très synthétique des qualités exigées de l’objet audité : cet

objet est conforme à ce qu’on attend de lui ou pas ».

Ensuite il dit aussi que « l'audit est surtout un outil d'amélioration continue, car il permet

de faire le point sur l'existant (état des lieux) afin d'en dégager les points faibles et/ou non

conformes (suivant les référentiels d'audit). Cela, afin de mener par la suite les actions

adéquates qui permettront de corriger les écarts et dysfonctionnements constatés »

(ANGOT : 2004).

Pour ce qui est de l’évaluation de la qualité d’une mission d’audit informatique, nous

pouvons dire que cette pratique est récente et revêt un caractère stratégique fondamental

pour le cabinet car il permet de se remettre en question et d’améliorer la qualité des audits

avenir. « Evaluer la qualité d’une mission d’audit revient vérifier la conformité de la

mission par rapport aux standards en vigueur dans le domaine de l’informatique,

(COLUMBA : 2008).

Ainsi nous serons amenés dans le cadre cette première partie, a décrire la conduite d’une

mission d’audit informatique (chapitre I), puis à mettre en place le référentiel pour évaluer

la qualité de la mission d’audit (chapitre II), ensuite dans le chapitre suivant nous

établirons notre méthodologie de la recherche relatif au sujet traité.

2 L’audit légal consiste à émettre une opinion sur la régularité et la sincérité des comptes annuels d’une entité et à valider qu'ils présentent une image fidèle de l'entité, la pertinence et la qualité de l’information financière.




CHAPITRE I : CONDUITE D’UNE MISSION D’AUDIT CONTRACTUEL

D’après Wikipédia (2012), l’audit informatique est vu le jour dans les années 19603 aux

USA. Il est devenu omniprésente et indispensable pour les entreprises qui veulent avoir un

système d’information performant. N’oublions pas que l’informatique est la gestion

automatisée de l’information. Selon BOMBAL, (2006: 8), « pour un décideur, l’audit est

un outil permettant de mesurer la performance de son système et des processus connexes.

L’audit est un moyen préventif bien qu’utilisé trop souvent à titre curatif dans 58% des cas.

L’audit informatique s’impose car il y a une prise de conscience de la part des dirigeants

d’entreprise ».

Comme son nom l’indique ce chapitre sera consacré dans la première partie à la définition,

aux objectifs de l’audit ensuite nous allons décrire la conduite d’une mission d’audit. Nous

parlerons des normes professionnelles de l’audit ainsi que de la méthodologie de l’audit

informatique.

1.1. Définition et objectif d’une mission d’Audit informatique

D’après les normes ISACA4 (2008 :7), « l’audit informatique, évalue les risques d'un

environnement informatique ou d'une application. Ces missions se font en choisissant avec

le client les processus métiers à évaluer ».

L'audit informatique peut concerner l'évaluation des risques informatiques de la sécurité

physique, de la sécurité logique, de la gestion des changements, ou bien un ensemble de

3 D’après WIKIPEDIA(2012), l’audit (anglicisme issu d'une locution latine proche des notions de contrôle, vérification, expertise, évaluation, etc.) vient du verbe latin audire, écouter. Les Romains employaient ce terme pour désigner un contrôle au nom de l’empereur sur la gestion des provinces. Il fut introduit par les Anglo-Saxons au début du xiiie siècle pour la gestion. Le premier cabinet d’audit fut fondé au xive siècle à Londres. L’audit informatique quant à lui arrive aux états unis dans les années 1960 pour garantir le respect des standards internationaux.

4 L`ISACA est une association professionnelle internationale dont l'objectif est d'améliorer la gouvernance des systèmes d'information, notamment par l'amélioration des méthodes d'audit informatique. Elle est aussi l'organisme promoteur des référentiels de meilleures pratiques COBIT, pour les volets audit et gouvernance, et Val IT pour les aspects alignement stratégique et création de valeur. Elle est membre affiliée de la fédération internationale des comptables




processus informatiques. Par exemple, apprécier la disponibilité des informations et des

systèmes.

Un audit informatique, ne concerne pas nécessairement la sécurité. En effet, il peut servir à

évaluer des aspects stratégiques ou de qualité des systèmes d'information.

1.2. Les concepts de base de l'audit informatique

Selon THORIN (1997 : 10) « la notion de contrôle est au cœur de la démarche d'audit

informatique. L'objectif est de mettre en place des dispositifs de contrôle efficaces et

performants permettant de maîtriser efficacement l'activité informatique. Le contrôle

interne un processus mis en œuvre à l'initiative des dirigeants de l'entreprise et destiné à

fournir une assurance raisonnable quant à la réalisation des objectifs suivants :

o la conformité aux lois et aux règlements,

o la réalisation et l'optimisation des opérations.

Il est évident que l'audit informatique s'intéresse surtout au second objectif.

« L’auditeur va s'attacher à relever des faits puis il va mener des entretiens avec les

intéressés concernés. Il va ensuite s'efforcer d'évaluer ses observations par rapport à des

référentiels largement reconnus. Sur cette base il va proposer des recommandations »

(THORIN 1997 : 10).

Dans le support de cours de BLE KOFFI (2013), sur l’audit des systèmes d’informations, il

nous apprend que l'auditeur informatique va se servir de référentiels d'audit informatique

lui donnant l'état des bonnes pratiques dans ce domaine. Le référentiel de base est le

COBIT: Control Objectives for Information and related Technology.

Le référentiel COBIT (Control objectives for information and related technology), a été

conçu par l'ISACA (2012), (Information System Audit and Control Association) et dont

l’AFAI5 (2012), est le correspondant en France. Il s’agit d’un cadre de référence ainsi

5 L'Association française de l’audit et du conseil informatiques est l'association regroupant les professionnels de l'audit et du conseil en des systèmes d'information en France. Elle a été créée en 1982. Elle se consacre à


http://fr.wikipedia.org/wiki/CobiT



qu'un ensemble d'outils pour assurer la maîtrise et l’audit de la gouvernance du SI d’une

structure. Le COBIT est fondé sur un ensemble de bonnes pratiques collectées auprès

d'experts SI.

Le référentiel COBIT propose d'établir un cadre de pilotage orienté processus du Système

d'Information afin de contribuer efficacement à l'alignement des technologies sur la

stratégie d'entreprise. Il a pour ambition de placer les solutions techniques et les risques

business dans une logique de contrôle et de management. La démarche s'inscrit dans une

dynamique d'amélioration continue, elle généralise la pratique de l'audit et garantie la

gestion des risques.

COBIT se base sur l'analyse et l'harmonisation des standards informatiques existants

comme sur les bonnes pratiques, et se conforme aux principes de gouvernance

généralement acceptés. Il considère les exigences métiers au niveau le plus général et

couvre l'ensemble des activités informatiques en se concentrant sur ce qui doit être

accompli plutôt que sur la façon de réussir une gouvernance, une gestion et un contrôle

efficaces des activités. Il agit donc comme un intégrateur des pratiques de gouvernance des

SI et s'adresse aux directions générales, au management des métiers et de l'informatique,

aux professionnels de la gouvernance, de l'assurance et de la sécurité comme à ceux de

l'audit et du contrôle informatique. Il est conçu pour être complémentaire d'autres standards

et des bonnes pratiques et pour être utilisé conjointement avec eux.

La mise en place des bonnes pratiques doit être cohérente avec la gouvernance de

l'entreprise et avec le cadre de contrôle, appropriée à l'entreprise et intégrée aux autres

méthodes et pratiques utilisées. Les standards et les bonnes pratiques ne sont pas la

panacée. Leur efficacité dépend de la façon dont ils ont été mis en œuvre et dont ils sont

tenus à jour. Ils sont plus utiles lorsqu'on les applique comme un ensemble de principes et

comme point de départ pour l'élaboration de procédures spécifiques sur mesure. Pour éviter

que les pratiques restent au niveau des bonnes intentions, le management et le personnel

doivent comprendre quoi faire, comment le faire et pourquoi c'est important.

l'audit informatique et à la maîtrise des systèmes d'information. Elle a vocation de favoriser le développement des méthodes et des techniques d’audit et de contrôle de l’informatique.




Pour réussir l'alignement des bonnes pratiques sur les exigences métiers, il est recommandé

d'utiliser COBIT au niveau le plus général, ce qui fournira un cadre de contrôle global basé

sur un modèle de processus informatiques génériques qui convient habituellement à toutes

les entreprises. Les pratiques spécifiques et les standards qui intéressent des domaines

particuliers peuvent être mis en regard du cadre de référence COBIT, fournissant ainsi un

ensemble hiérarchisé de guides.

COBIT concerne différents types d'utilisateurs :

o les directions générales : pour que l'investissement informatique produise de la

valeur et pour trouver le bon équilibre entre risques et investissements en contrôles,

dans un environnement informatique souvent imprévisible ;

o les directions métiers : pour obtenir des assurances sur la gestion et le contrôle des

services informatiques fournis en interne ou par des tiers ;

o les directions informatiques : pour fournir les services informatiques dont les

métiers ont besoin pour répondre à la stratégie de l'entreprise, et pour contrôler et

bien gérer ces services ;

o les auditeurs : pour justifier leurs opinions et/ou donner des conseils au

management sur les dispositifs de contrôle interne.

COBIT a été développé et est maintenu à jour par un institut indépendant et sans but

lucratif, puisant dans l'expertise des membres de ses associations affiliées, des experts du

monde des affaires et des professionnels du contrôle et de la sécurité. Son contenu est basé

sur une recherche permanente des bonnes pratiques de l'informatique et il est

continuellement mis à jour, offrant ainsi un objectif et des ressources pratiques à tous les

types d'utilisateurs.

COBIT est axé sur les objectifs et sur la perspective de la gouvernance des SI. Il s'assure

que son cadre de référence en englobe bien tous les aspects, en accord avec les principes de

la gouvernance d'entreprise et, par conséquent, qu'il peut être accepté par les

administrateurs, dirigeants, auditeurs et régulateurs.

Le COBIT est structuré selon 34 processus regroupés en ces domaines :

o planning et organisation: comment utiliser au mieux les technologies afin que

l'entreprise atteigne ses objectifs ;




o acquisition et mise en place : comment définir, acquérir et mettre en œuvre les

technologies nécessaires en adéquation avec les business processus de l'entreprise.

Le COBIT agit comme un intégrateur des différents guides (ITIL, ISO 9000, CMMI) en

réunissant les objectifs de gouvernance et les exigences des métiers. Le COBIT est

généralement considéré comme le cadre de référence de la gestion et du contrôle des

systèmes d’information.

L’adoption du COBIT comme cadre de gouvernance des systèmes d’information offre les

avantages suivants :

o une meilleure harmonisation de l’informatique et de l’activité de l’entreprise du fait

de son orientation métier ;

o une compréhension partagée par toutes les parties prenantes grâce à un langage

commun ;

o une vision compréhensible de ce qu’apporte l’informatique à la gestion de

l’entreprise ;

o une attribution de la propriété et des responsabilités, du fait de l’approche par

processus ;

o une adoption généralisée de la part des tiers et des organismes de contrôles ;

o le respect des exigences du COSO6 pour le contrôle de l’environnement

informatique.

1.3. Différents types d'audit informatique.

DERRIEN (1992 : 20) affirme que « la démarche d'audit informatique est générale et

s'applique à différents domaines comme la fonction informatique, les études informatiques,

les projets informatiques, l'exploitation, la planification de l'informatique, les réseaux et les

télécommunications, la sécurité informatique, les achats informatiques, l'informatique

locale ou l'informatique décentralisée, la qualité de service, l'externalisation, la gestion de

6 Le COSO est un référentiel de contrôle défini par le Committee Of Sponsoring Organisations of the Treadway Commission. Il est utilisé dans la mise en place des dispositions relevant des lois SOX ou Loi de sécurité financière, pour les entreprises assujetties respectivement aux lois américaines ou françaises.




parc, les applications opérationnelles ». Selon WIKIPEDIA (2012), il existe les audits

informatiques suivants :

1.3.1. Audit de l’organisation de la fonction informatique

C’est l’audit qui concerne notre étude. Le but de l'audit de la fonction informatique est de

répondre aux préoccupations du demandeur qui est ici le MEF, concernant l'organisation

de la fonction informatique, son pilotage, son positionnement dans la structure, ses

relations avec les utilisateurs, ses méthodes de travail…

Selon DERRIEN (1992), pour effectuer un audit de la fonction informatique on se base sur

les bonnes pratiques connues en matière d'organisation de la fonction informatique. Elles

sont nombreuses et bien connues, parmi celles-ci on peut citer :

o la clarté des structures et des responsabilités de l'équipe informatique,

o la définition des relations entre la direction générale, les directions fonctionnelles et

opérationnelles et la fonction informatique,

o l'existence de dispositifs de mesures de l'activité et notamment d'un tableau de bord

de la fonction informatique,

o le niveau des compétences et des qualifications du personnel de la fonction.

Il existe de nombreuses autres bonnes pratiques concernant la fonction informatique. Pour

auditer la fonction on va se baser sur ces bonnes pratiques afin de dégager un certain

nombre d'objectifs de contrôle comme :

o la mise en œuvre de politiques, de normes et de procédures spécifiques à la

fonction,

o l'existence de mécanismes permettant de connaître et de suivre les coûts

informatiques, soit à l'aide d'une comptabilité analytique, soit, à défaut, grâce à un

mécanisme de refacturation,

o le respect des dispositifs de contrôle interne comme une évaluation périodique des

risques, la mesure de l'impact de l'informatique sur les performances de l'entreprise.




1.3.2. Audit des études informatiques

Selon WIKIPEDIA (2012), l'audit des études informatiques est un sous-ensemble de l'audit

de la fonction informatique. Le but de cet audit est de s'assurer que son organisation et sa

structure sont efficaces, que son pilotage est adapté, que ses différentes activités sont

maîtrisées, que ses relations avec les utilisateurs se déroulent normalement.

Pour effectuer un audit des études informatiques on se base sur la connaissance des bonnes

pratiques recensées dans ce domaine. Elles sont nombreuses et connues par tous les

professionnels. Parmi celles-ci on peut citer :

o l'organisation de la fonction études en équipes, le choix des personnes et leur

formation, leurs responsabilités ;

o la mise en place d'outils et de méthodes adaptés notamment une claire identification

des tâches, des plannings, des budgets, des dispositifs de suivi des études, un

tableaux de bord ;

o le contrôle des différentes activités qui ne peuvent pas être planifiées comme les

petits projets, les projets urgents ;

o la mise sous contrôle de la maintenance des applications opérationnelles,

o le suivi des activités d'études à partir de feuilles de temps.

Pour REIX & ROW (2011), il existe de nombreuses autres bonnes pratiques7

concernant les études informatiques. Pour l'auditer on va se baser sur ces bonnes pratiques

afin de dégager un certain nombre d'objectifs de contrôle comme :

o l'évaluation de l'organisation de la fonction d'études informatiques et notamment la

manière dont sont planifié les différentes activités d'études ;

o le respect de normes en matière de documentation des applications et notamment la

définition des documents à fournir avec les différents livrables prévues ;

o le contrôle de la sous-traitance notamment la qualité des contrats, le respect des

coûts et des délais, la qualité des livrables ;

7 D’apes l’AFAI(2012), les référentiels pertinents de l’audit informatique sont les suivants : o Le Cobit pour la gouvernance des SI. loi de la sécurité financière (LSF) ; o La loi informatique et liberté ; o référentiel de méthodes d’analyse de risques (EBIOS, MEHARI, OCTAVE, CRAM) concernant

l’identification, estimation et évaluation des risques.




o l'évaluation de la qualité des livrables fournis par les différentes activités d'études

qui doivent être testables et vérifiables.

Il existe de nombreux autres objectifs de contrôle concernant les études informatiques et ils

sont choisis en fonctions des préoccupations du demandeur d'audit.

1.3.3. Audit de l'exploitation

« L'audit de l'exploitation a pour but de s'assurer que le ou les différents centres de

production informatiques fonctionnent de manière efficace et qu'ils sont correctement

gérés », (THORIN : 1997).

Pour effectuer un audit de l'exploitation on se base sur la connaissance des bonnes

pratiques concernant ce domaine comme :

o la clarté de l'organisation de la fonction notamment le découpage en équipes, la

définition des responsabilités ;

o l'existence d'un système d'information dédié à l'exploitation notamment pour suivre

la gestion des incidents, la gestion des ressources, la planification des travaux, les

procédures d’exploitation ;

o la mesure de l'efficacité et de la qualité des services fournies par l'exploitation

informatique.

THORIN (1997), affirme « qu’il existe de nombreuses autres bonnes pratiques concernant

l'exploitation informatique. Pour effectuer cet audit on va se baser sur ces bonnes pratiques

afin de dégager un certain nombre d'objectifs de contrôle comme :

o la qualité de la planification de la production,

o la gestion des ressources grâce à des outils de mesure de la charge, des simulations,

le suivi des performances,

o l'existence de procédures permettant de faire fonctionner l'exploitation en mode

dégradé de façon à faire face à une indisponibilité totale ou partielle du site central

ou du réseau,

o la gestion des incidents de façon à les repérer et le cas échéant d'empêcher qu'ils se

renouvellent,




o les procédures de sécurité et de continuité de service qui doivent se traduire par un

plan de secours,

o la maîtrise des coûts de production grâce à une comptabilité analytique permettant

de calculer les coûts complets des produits ou des services fournis ».

1.3.4. Audit des projets informatiques

L'audit des projets informatiques est un audit dont le but est de s'assurer qu'il se déroule

normalement et que l'enchaînement des opérations se fait de manière logique et efficace de

façon qu'on ait de fortes chances d'arriver à la fin de la phase de développement à une

application qui sera performante et opérationnelle. Comme on le voit un audit d'un projet

informatique ne se confond pas avec un audit des études informatiques.

Pour effectuer un audit d'un projet informatique on se base sur la connaissance des bonnes

pratiques connues en ce domaine. Elles sont nombreuses et connues par tous les chefs de

projets et de manière plus générale par tous professionnels concernés.

L’audit de la qualité de la conduite du projet vise à apprécier si la conduite de projet est

conforme à une méthodologie d’entreprise, à des normes internationales, ou à l’état de

l’art, et si les coûts et délais sont maîtrisés.

Trois composantes : qualité, coûts, délais

L’audit de la qualité du produit a pour objectif de vérifier l’adéquation entre les besoins

des utilisateurs et le produit à livrer ou fini.

L’audit pourra porter sur :

o l’adéquation des choix techniques aux besoins (pérennité, disponibilité, performance…)

o la qualité de la solution technique (robustesse, évolutivité…) o l’appréciation de la sécurité de la future application o la qualité des développements o la qualité des tests et recettes o la maîtrise de l’intégration dans le SI.




1.3.5. Audit des applications opérationnelles

Les audits précédents sont des audits informatiques, alors que l'audit d'applications

opérationnelles couvre un domaine plus large et s'intéresse au système d'information de

l'entreprise. Ce sont des audits du système d'information. Ce peut être l'audit de

l'application comptable, de la paie, de la facturation. Mais, de plus en plus souvent, on

s'intéresse à l'audit d'un processus global de l'entreprise comme les ventes, la production,

les achats, la logistique.

Il est conseillé d'auditer une application de gestion tous les deux ou trois ans de façon à

s'assurer qu'elle fonctionne correctement et, le cas échéant pouvoir apporter les

améliorations souhaitables à cette application ou à ce processus. L'auditeur va notamment

s'assurer du respect et de l'application des règles de contrôle interne. Il va en particulier

vérifier que :

o les contrôles en place sont opérationnels et sont suffisants,

o les données saisies, stockées ou produites par les traitements sont de bonnes

qualités,

o les traitements sont efficaces et donnent les résultats attendus,

o l'application est correctement documentée,

o les procédures mises en œuvre dans le cadre de l'application sont à jour et adaptées,

o l'exploitation informatique de l'application se fait dans de bonnes conditions,

o la fonction ou le processus couvert par l'application est efficace et productif.

Le but de l'audit d'une application opérationnelle est de donner au management une

assurance raisonnable sur son fonctionnement. Ces contrôles sont, par exemple, réalisés

par le Commissaire aux Comptes dans le cadre de sa mission légale d'évaluation des

comptes d'une entreprise : est-ce que le logiciel utilisé est sûr, efficace et adapté ?

1.3.6. Audit de la sécurité informatique

L'audit de la sécurité informatique a pour but de donner au management une assurance

raisonnable du niveau de risque de l'entreprise lié à des défauts de sécurité informatique.

En effet, l'observation montre que l'informatique représente souvent un niveau élevé pour

risque élevé de l'entreprise.




Pour effectuer un audit de sécurité informatique il est nécessaire de se baser sur quelques

objectifs de contrôle. Les plus courants sont :

o repérer les actifs informationnels de l'entreprise. Ce sont des matériels

informatiques, des logiciels et des bases de données. Il est pour cela nécessaire

d'avoir des procédures de gestion efficaces et adaptées,

o évaluer les menaces, le responsable de la sécurité a la responsabilité de repérer les

principaux risques liés aux différents domaines du système d'information. Un

document doit recenser les principales menaces.

1.4. Code déontologique

Ce sont les règles de conduite pour promouvoir l’éthique au sein de la profession

(ISACA 2008 :S2)

1.4.1. Principes fondamentaux

Il est attendu des auditeurs qu’ils appliquent les principes suivants :

o intégrité : faite d’honnêteté, de probité, de désintéressement et d’incorruptibilité ;

o objectivité : c’est-à-dire une attitude d’esprit exempte de préjugé et de partialité ;

o compétence : faite de connaissances à jour, de capacité et d’aptitude à la mise en

œuvre de ces compétences, dont dépendent la pertinence et la qualité des travaux

effectués et de l’opinion émise ;

1.4.2. Règles de conduite

Il est attendu des auditeurs qu’ils appliquent les règles de conduite suivantes (ISACA

2008 : S3) :

o indépendance professionnelle dans tous les aspects de l’audit, l’auditeur doit être

indépendant de l’audité en attitude et en apparence ;

o le cabinet d’audit doit être indépendant du département ou de l’activité à contrôler

pour atteindre l’objectif visé par la mission d’audit ;

o si l’indépendance n’est pas respectée en attitude et en apparence, les détails de ce

manquement doivent être communiqués aux parties.




o l’indépendance doit être évaluée régulièrement par l’auditeur.

o sauf interdiction par d’autres normes professionnelles ou organismes

réglementaires, l’auditeur n’est pas tenu d’être, y compris en apparence,

indépendant si la nature de son implication dans le domaine des SI ne relève pas de

l’audit.

o l’auditeur doit adhérer au code d’éthique professionnelle de l’ISACA.

o les auditeurs doivent connaître les dernières Normes d’audit en vigueur et réaliser

leurs missions d’audit avec toute la conscience professionnelle requise.

o les auditeurs doivent traiter de manière adéquate tous les problèmes liés au respect

de l’éthique professionnelle ou des Normes d’audit des SI lorsqu’ils effectuent

leurs missions d’audit. Si l’éthique professionnelle ou les Normes d’audit des SI ne

sont pas respectées y compris en apparence, l’auditeur des SI doit envisager de

mettre fin à sa mission.

o l’auditeur doit conserver une attitude et une intégrité irréprochables et ne pas

employer de méthodes susceptibles d’être interprétées comme illégales, contraires à

l’éthique ou non professionnelles pour obtenir ou réaliser des missions d’audit.

o l’auditeur doit être professionnellement compétent, c’est-à-dire posséder les

aptitudes et connaissances nécessaires pour mener à bien ses missions d’audit.

o il doit entretenir ces compétences professionnelles en suivant des programmes de

formation professionnelle continue.

1.5. Normes de l’audit

A ce niveau les normes ISACA (2008), nous apprennent que nous avons la définition de la

mission, son étendue, ainsi que les pouvoirs conférés aux auditeurs. Il est composé par ce

qui suit : les objectifs de la mission, la faisabilité de la mission d'audit (ressources

suffisantes, délais,...) l’étendue de la mission ou les processus concernés la nature de la

mission d'audit (ressources humaines, ressources technologiques, organisation,

communication,...) les délais de la mission, les auditeurs responsables de la mission, la

description du déroulement de la mission, l’organisation ou non d'une réunion d'ouverture

avec l'ensemble du personnel (destinataires du rapport), le plan d'action.

Le compte rendu de la réunion est envoyé aux personnes présentes à la réunion lesquelles

disposent d'un délai pour communiquer leurs éventuelles modifications et/ou

commentaires.




1.5.1. Normes de qualification

L’auditeur doit posséder les compétences suivantes (ISACA 2008 : S2) :

o l’auditeur des SI doit attester de compétences professionnelles suffisantes

(aptitudes, connaissances et expérience pertinentes pour la mission concernée)

avant de commencer son travail. Dans le cas contraire, l’auditeur des SI doit refuser

ou se retirer de la mission.

o s’il possède les compétences requises, l’auditeur doit satisfaire aux exigences de

formation ou de développement professionnel continus de la CISA8, ainsi qu’aux

autres charges professionnelles liées à l’audit. Les membres de l’ISACA non

titulaires de la certification CISA ou d’un autre titre d’auditeur professionnel et qui

sont impliqués dans un quelconque audit doivent posséder une formation et une

expérience professionnelles suffisantes.

o si l’auditeur dirige une équipe chargée du contrôle, il doit attester que tous ses

membres possèdent le niveau de compétences professionnelles requis pour la tâche

à exécuter.

1.5.2. Normes de fonctionnement

A ce niveau nous expliquerons les différentes phases d’une mission d’audit informatique :

1.5.2.1. La lettre de mission

Selon la norme ISACA (2008 : S1), la lettre de mission doit être avalisée au niveau

approprié au sein du MEF dans notre cas. L’auditeur peut utiliser une lettre de mission

pour clarifier plus avant ou confirmer les implications dans des missions spécifiques

d’audit ou de non audit. S’agissant d’un audit externe des SI, une lettre de mission doit

normalement être préparée pour chaque mission d’audit ou de non-audit. La charte d’audit

ou la lettre de mission doit être suffisamment détaillée pour communiquer l’objectif, les

responsabilités et les limites de la fonction ou de la mission d’audit.

8 Depuis 1978, le programme des Auditeurs Certifiés de Systèmes d’Information (Certified Information

Systems Auditor) en sigle CISA, parrainé par ISACA, est une norme mondialement acceptée de

reconnaissance parmi les professionnels de l’audit, du contrôle et de la sécurité des systèmes d’information.




La lettre de mission doit être révisée régulièrement pour vérifier que l’objectif et les

responsabilités ont été correctement documentés. La lettre de mission doit aborder les

thèmes de l’indépendance et de la responsabilité au sein de la fonction d’audit.

1.5.2.2. Planification

Selon BITTERLI (2008 : 5) « dans le cadre des procédures d’audit orientées processus et

basées sur l’utilisation d’applications informatiques, il est essentiel de prendre en compte

tous les domaines importants, y compris les des domaines IT spécifiques ayant une

influence significative sur l’objectif de contrôle de l’auditeur. Pour y parvenir une

approche de contrôle intégrée de l’auditeur informatique est nécessaire ».

Selon la norme S5 l’auditeur des SI doit planifier la portée de l’audit des systèmes

d’information pour atteindre ses objectifs et se conformer aux lois et aux normes d’audit

professionnel en vigueur. Un plan doit normalement être préparé pour chaque mission

d’audit ou de non-audit. Le plan doit comporter les objectifs de l’audit. L’auditeur des SI

doit comprendre la nature de l’activité à contrôler. L’étendue des connaissances requises

doit être déterminée par la nature de l’entreprise, son environnement, les risques et les

objectifs de l’audit.

L’auditeur des SI doit effectuer une évaluation des risques pour attester que tous les

éléments matériels seront couverts de manière appropriée au cours de l’audit. Les

stratégies d’audit, les seuils de tolérance et les ressources peuvent alors être développés. Le

programme et/ou le plan d’audit peuvent nécessiter un réajustement en cours d’audit pour

régler les problèmes (nouveaux risques, prévisions erronées ou conclusions des procédures

déjà effectuées) pouvant survenir durant l’audit.

L’auditeur des SI doit utiliser une technique ou une approche d’évaluation des risques

appropriée pour développer le plan général d’audit des SI et pour déterminer les priorités

en matière d’affectation des ressources d’audit des SI.

1.5.2.3. Réunion d'ouverture

La norme ISACA (2008 :55), nous apprend que la réunion d'ouverture a pour but d'établir

les premiers contacts avec l'ensemble des personnes impliquées par l'audit avant de débuter

les travaux. La réunion d'ouverture est facultative : les auditeurs et la direction de l'entité




auditée décident de l'organisation d'une réunion d'ouverture. Pour les missions qui

exigeraient la présence de beaucoup de personnes, il peut être plus aisé de transmettre une

note explicative. Toutefois, quand c'est possible, l'organisation d'une réunion d'ouverture

est toujours préférable. Les personnes présentes à cette présentation : les auditeurs chargés

de la mission, la Direction de ou des entité(s) auditée(s), l'ensemble du personnel de ou des

entité(s) auditée(s) ou les responsables des processus audités.

1.5.2.4. Réalisation du travail d’audit

Le personnel d’audit des SI doit être supervisé pour attester que les objectifs de l’audit sont

atteints et que les normes d’audit professionnel en vigueur sont respectées. Pendant l’audit,

l’auditeur des SI doit recueillir des éléments probants pertinents, suffisants et fiables pour

atteindre les objectifs de l’audit (ISACA 2008 :S6). Les conclusions de l’audit doivent être

appuyées par une analyse et une interprétation adéquates de ces éléments probants. Le

processus d’audit doit être documenté pour décrire le travail d’audit et les éléments

probants qui étayent les conclusions de l’auditeur des SI.

Les rôles et responsabilités d’une équipe d’audit des SI doivent être établis au début de

l’audit, en définissant des rôles minimums de décision, d’exécution et de révision.

Le travail exécuté pendant la mission doit être organisé et documenté conformément aux

procédures prédéfinies suivantes. La documentation doit comporter des éléments tels que

les objectifs et la portée de la mission, le programme d’audit, les étapes d’audit réalisées,

les éléments probants rassemblés, les conclusions et les recommandations.

La documentation d’audit doit être suffisamment abondante pour qu’un tiers indépendant

puisse effectuer de nouveau toutes les tâches réalisées pendant l’audit et aboutir aux

mêmes conclusions.

La documentation d’audit doit inclure des informations sur l’identité et les rôles des

personnes ayant effectué chaque tâche d’audit. En général, chaque tâche, décision, étape ou

résultat de l’audit réalisé par un ou plusieurs membres de l’équipe doit être révisé par une

autre personne de l’équipe, nommée en fonction de l’importance de l’élément visé.




L’auditeur des SI doit planifier l’utilisation d’éléments probants accessibles et cohérents

avec l’importance de l’objectif de l’audit, avec le temps passé et avec les efforts mis en

œuvre pour obtenir lesdits éléments.

Les éléments probants de l’audit doivent être suffisants, fiables et pertinents pour donner

lieu à une opinion ou appuyer les conclusions de l’auditeur des SI. Si, d’après l’auditeur

des SI, les éléments probants obtenus ne remplissent pas ces critères, il doit acquérir des

éléments probants supplémentaires. Se référer aux instructions suivantes pour plus

d’informations sur la réalisation du travail d’audit.

1.5.2.5. Le compte rendu final

Le compte rendu final est la présentation orale, par le(s) responsable(s) de la mission au

principal responsable de l'entité auditée, des observations les plus importantes. Le but est

d'informer rapidement et en premier le responsable de l'entité auditée du résultat des

travaux d'audit et des conclusions dégagées. Cette présentation est effectuée à la fin du

travail de terrain et avant la rédaction du projet de rapport. Il s'agit d'une sorte de " pré-

validation " générale. Ce compte rendu nécessite de l'équipe d'audit la parfaite maîtrise de

ses conclusions et engage sa crédibilité.

1.5.2.6. Rapport

La présente Norme d’audit des SI (ISACA 2008 :S7) a pour objectif l’établissement et la

promulgation d’instructions concernant les rapports de sorte que l’auditeur des SI puisse

mener à bien le reporting.

À l’issue de son travail, l’auditeur des SI doit fournir un rapport sous une forme adéquate.

Le rapport doit préciser l’entreprise, les destinataires du document et les éventuelles

restrictions à sa diffusion. Le rapport doit indiquer la portée, les objectifs, la période

couverte, la nature, la durée et l’ampleur de l’audit réalisé. Le rapport doit indiquer les

conclusions et recommandations de l’audit, ainsi que les éventuelles limitations de portée,

réserves ou qualifications jugées opportunes par l’auditeur des SI.

L’auditeur des SI doit collecter des éléments probants suffisants et pertinents pour

corroborer les résultats rapportés. Lors de son édition, le rapport de l’auditeur des SI doit




être signé, daté et distribué conformément aux termes de la charte d’audit ou de la lettre de

mission.

La forme et le contenu du rapport varient généralement selon le type de service ou de

mission. L’auditeur des SI peut effectuer l’une des opérations suivantes : audit (direct ou

attestation), contrôle (direct ou attestation), procédures convenues.

Lorsque l’auditeur des SI doit donner son opinion sur l’environnement de contrôle

conformément aux termes de sa mission et que des éléments probants indiquent

l’insuffisance de certaines informations, l’auditeur des SI doit s’abstenir de conclure que

les contrôles internes sont efficaces. Le rapport de l’auditeur des SI doit décrire les

éléments ne jouissant pas de la pertinence requise et leurs effets sur l’application des

critères de contrôle.

L’auditeur des SI doit présenter aux dirigeants concernés une version préliminaire de son

rapport et discuter avec eux de son contenu avant la finalisation et la diffusion. Le cas

échéant, les commentaires des dirigeants doivent être inclus dans le rapport final.

Lorsque l’auditeur des SI remarque d’importantes déficiences dans l’environnement de

contrôle, il doit en faire part au comité d’audit ou aux autorités responsables et signaler

dans le rapport que lesdites déficiences importantes ont été décelées. Lorsque l’auditeur

des SI établit des rapports distincts, le rapport final doit faire référence à l’ensemble de ces

rapports.

L’auditeur des SI doit s’interroger sur l’opportunité de communiquer aux dirigeants les

déficiences du contrôle interne considérées comme moins importantes. Le cas échéant,

l’auditeur des SI doit signaler au comité d’audit ou à l’autorité responsable que lesdites

déficiences du contrôle interne ont été communiquées aux dirigeants.

L’auditeur des SI doit solliciter et examiner des informations pertinentes sur les

conclusions et recommandations des précédents rapports pour déterminer si les mesures

appropriées ont été mises en œuvre dans les délais impartis.

Se référer aux instructions suivantes pour plus d’informations sur les rapports :




1.5.2.7. Activités de suivi

Après l’édition d’un rapport sur les conclusions et les recommandations, l’auditeur des SI

doit solliciter et analyser des informations pertinentes pour évaluer si les mesures

adéquates ont été prises par les dirigeants dans les délais impartis.

Si les mesures proposées par les dirigeants pour mettre en œuvre les recommandations ont

été communiquées à l’auditeur des SI ou débattues avec lui, elles doivent être indiquées en

tant que réponse des dirigeants dans le rapport final. (ISACA 2008 : S8)

La nature, la durée et l’ampleur des activités de suivi doivent prendre en compte

l’importance des conclusions et les conséquences d’une absence de mesures correctives. La

durée des activités de suivi de l’audit des SI liées au rapport original est affaire de

jugement professionnel d’après un certain nombre de considérations, comme la nature ou

l’importance des risques et des coûts pour l’entreprise.

Un processus de suivi doit être établi par une fonction d’audit des SI interne pour vérifier

que les mesures des dirigeants ont été réellement appliquées ou que ces derniers ont

accepté le risque de ne pas agir. La responsabilité de ces activités de suivi peut être définie

dans la charte d’audit de la fonction.

Selon la portée et les termes de la mission, les auditeurs des SI externes peuvent s’appuyer

sur une fonction d’audit des SI interne pour assurer le suivi des recommandations

convenues.

Lorsque les dirigeants fournissent des informations sur les mesures prises afin de mettre en

œuvre les recommandations et que l’auditeur des SI doute de la qualité desdites

informations, des procédures s’imposent, notamment de test, pour vérifier la réalité des

faits avant de conclure.

Un rapport sur le statut des activités de suivi, notamment sur les recommandations

convenues mais non mises en œuvre, peut être remis au comité d’audit (si mis en place),

voire à l’échelon approprié de la direction de l’entreprise.

Dans le cadre des activités de suivi, l’auditeur des SI doit déterminer si ses conclusions

sont toujours valides malgré l’absence de mise en œuvre




Conclusion chapitre 1

Nous venons de présenter durant tout ce chapitre les différentes étapes du déroulement

d’une mission d’audit informatique, les outils et les techniques nécessaires à sa réalisation.

Ainsi étant en possession de tous les outils nécessaires au bon déroulement de notre audit,

nous allons au prochain chapitre développer une méthodologie pour l’évaluation de la

qualité de notre mission d’audit.




CHAPITRE 2 : QUALITE D’UNE MISSION D’AUDIT INFORMATIQUE.

Pour mieux préparer le travail qui nous incombe nous allons dans ce chapitre mettre à nue

les termes « évaluer et qualité » puis présenter les indicateurs que nous aurons choisis pour

évaluer notre mission d’audit. Ce chapitre répondra à la question de savoir comment

évaluer la qualité d’une mission d’audit.

2.1. Les caractéristiques de la qualité

« La qualité n'est pas la performance maximale, mais le respect de la performance

spécifiée » (Harbour : 1997 :10).

Selon la norme ISO9 9000 (2012), la non-qualité représente, quant à elle, globalement,

l'ensemble des écarts entre la qualité voulue et la qualité détenue. Dans un sens plus large,

elle est le contraire de la qualité. La qualité à obtenir est la qualité nécessaire et suffisante

répondant au besoin.

2.2. Objectifs et démarche d’évaluation de la qualité :

Nous allons décrire les objectifs et la démarche de notre évaluation

2.2.1. Objectifs d’une évaluation

D’après le dictionnaire LAROUSSE (2012), le mot évaluer peut être défini de la manière

suivante : « fixer la valeur de quelque chose ou bien fixer approximativement une qualité.

Dans ce cas précis c’est la seconde définition que nous allons retenir ».

Selon DETHIER (2007) « l'évaluation est un outil de mesure et de conduite du

changement. Elle a deux buts principaux : le but formatif, qui vise à améliorer la mise en

œuvre du programme, le but sommatif, qui analyse les effets du programme pour en tirer

les leçons ». Evaluer, c'est répondre à la question générique "Est-ce que ça marche ?".

9 D’après WIKIPEDIA (2012), l'organisation internationale de normalisation ou ISO est un organisme de

normalisation international composé de représentants d'organisations nationales de normalisation de 164

pays. Cette organisation créée en 1947 a pour but de produire des normes internationales dans les domaines

industriels et commerciaux appelées normes ISO. Elles sont utiles aux organisations industrielles et

économiques de tout type, aux gouvernements.




Toutes les définitions de l’évaluation associent trois dimensions : une collecte

d'informations systématique et diversifiée, une appréciation critique portée en référence à

des critères et des normes. Des recommandations en vue d'une décision.

Evaluer la qualité de notre mission d’audit, c'est l'améliorer en vue d'atteindre les objectifs

des cabinets d’audit informatique en général et ceux du cabinet Qualisys en particulier.

Selon la norme ISO 900010 (2012), la non-qualité représente, l'ensemble des écarts entre la

qualité voulue et la qualité détenue. Elle est le contraire de la qualité. La qualité à obtenir

est la qualité nécessaire et suffisante répondant au besoin. Elle peut être caractérisée par le

maintien de la conformité, et le respect des standards internationaux sur la question.

L’évaluation de la qualité nécessite de prendre en compte les éléments de qualité dictée par

l’AFAI (2012), concernant les processus à couvrir lors d’une mission d’audit informatique.

2.2.2. Démarche d’évaluation de la qualité

Pour évaluer notre mission, nous allons utiliser certaines techniques et outils qui vont nous

permettre d'apprécier la qualité de cette mission afin de pouvoir proposer des

recommandations.

« Il faut éviter toute fascination pour les outils qui sont parfois un leurre, n’hésitons pas à

constater qu’une méthode est indispensable pour évaluer et entreprendre une démarche

qualité. Il s’agit d’abord de distinguer l’évaluation et la démarche qualité elle-même, la

première étant un des moyens d’atteindre la seconde. Il y a entre évaluation et démarche

qualité un ordre logique et chronologique » (LAFORCADE : 2004).

Selon LAFORCADE (2004), l’évaluation de la qualité se distingue par quatre étapes

successives que nous allons développer.

La première étape est une étape descriptive. C’est le moment où l’on décrit dans une

politique ce qui s’est passé. Cela suppose bien évidemment d’avoir mis en place au

préalable un système d’information permettant de recueillir l’ensemble des données, des

10 ISO 9000 désigne un ensemble de normes relatives à la gestion de la qualité publiées par l'Organisation internationale de normalisation (ISO).




informations que l’on a considérées comme pertinentes et qui dans une étape ultérieure

seront évaluées.

La deuxième étape est l’étape analytique, celle où l’on décrit ce qui aurait dû se passer, elle

suppose la construction de standards, de normes, de référentiels.

La troisième étape est dite interprétative c’est celle où l’on va mesurer et interpréter la

différence entre la première étape et la seconde, la différence entre ce qui s’est passé et ce

qui aurait dû se passer.

La quatrième étape est celle d’aide à la décision. Afin de diminuer la distance entre ce que

l’on fait et ce que l’on devrait faire, une démarche qualité se met en place. Elle sera elle-

même évaluée et l’on retrouve donc cette vis sans fin de l’évaluation et de la démarche

qualité.

Une des étapes les plus structurantes de l’évaluation est donc bien sûr celle de la

construction des référentiels. L’utilisation de ces référentiels est indispensable pour

permettre de sortir de l’indicible, d’objectiver et de dépasser la phase incantatoire, elle

permet aussi d’essayer de sortir autant que possible de la subjectivité de tel ou tel, le

responsable ou le directeur par exemple qui s’arrogerait le droit d’évaluer à l’aune de ses

propres références, la plupart du temps non écrites ou simplement intuitives.

2.3. Indicateurs de la qualité d’une mission d’audit informatique:

DETHIER (2007), définit l’indicateur comme étant est « un outil d'évaluation et d'aide à la

décision, à la normalisation, à la gestion, grâce auquel on peut mesurer quantitativement ou

qualitativement une situation ou une tendance, de façon relativement objective, à un instant

donné, ou dans le temps et/ou l'espace. Ils peuvent être mesurable sur une échelle ou

quantifiable. L’indicateur est un outil universel ».

Dans notre cas précis nous avons choisi les meilleures pratiques de l’audit informatique

comme indicateurs de la qualité de notre mission d’audit.

2.3.1. Planification

Nous allons développer les indicateurs liés à la planification d’une mission d’audit




2.3.1.1. Objectifs de l’évaluation des risques informatiques

Le risque est un concept selon lequel l’entreprise exprime ses inquiétudes concernant les

effets probables d’un événement sur les objectifs de l’entité dans un environnement

incertain. Dans la mesure où il est imprévisible, l’entreprise doit tenir compte d’une

gamme d’événements possibles qui pourraient intervenir dans un univers incertain. Chacun

de ces événements pourrait avoir une conséquence significative sur l’entité et sur ses

objectifs : les effets négatifs sont qualifiés de « risques » et les effets positifs d’

« opportunités ».

L’incertitude et l’aléa sont inhérents à la conduite des affaires, à la réalisation de l’objet

d’une personne morales à but non lucratif ou à la réalisation d’une mission de service

public. Dans la mesure où il est contrôlé (maitrisé), le risque issu de cette incertitude et de

cet aléa n’est pas inquiétant en soi. La gestion des risques inclut l’analyse de ces risques et

une démarche prudente et progressive conduisant à une meilleure compréhension et à une

plus grande appréhension des conséquences de la gestion dans un monde incertain.

Par conséquent, l’évaluation et la gestion des risques par l’entreprise sont les deux outils

modernes de planification de la gestion. Le lien entre l’audit et la gestion des risques se

trouve dans l’évaluation des risques et de ses conséquences sur la réalisation des objectifs

définis.

L'objectif du processus d'évaluation des risques consiste à éliminer un danger ou à réduire

le niveau de risque en instaurant des mesures de maîtrise ou en adoptant des précautions

appropriées, s'il y a lieu.

Au niveau de l’entreprise, l’évaluation des risques va permettre à travers la cartographie

des risques d’atteindre trois objectifs :

o inventorier, évaluer et classer les risques de l’organisation

o informer les dirigeants pour une meilleure adaptation des activités au management

des risques

o l’élaboration d’une politique des risques par la direction générale avec l’aide du

risk manager. Cette politique s’imposera aux responsables opérationnels et aux

auditeurs internes.




L’évaluation des risques sert de base à la programmation des missions d’audit au sein de

l’entreprise.

2.3.1.2. Identification des risques informatiques

C’est le passage obligé dans la construction d’une structure rationnelle et globale de

gestion des risques pour permettre l’élaboration d’un contrôle interne efficace. En effet

c’est le point de départ pour une évaluation des risques. L’identification requiert une

connaissance appropriée et une compréhension des activités de l’entreprise.

Plusieurs techniques d’identification ont été élaborées par différents auteurs aussi, les

techniques d’identification des risques utilisées sont :

o Identification par découpage de l’activité en tache élémentaires : il s’agit

d’identifier et lister toutes les tâches élémentaires de l’activité si possible de façon

séquentielle. Le découpage permettra de connaitre les risques que l’entreprise

encourt si l’une des tâches n’est pas exécutée ou est mal exécutée ;

o Identification prenant en compte l’atteinte des objectifs : elle débutera par une

identification claire et précise des objectifs de l’entreprise, ensuite à chaque objectif

sera affectée la menace qui lui correspond. Cette technique est assez complexe dans

sa réalisation ;

o Identification basée sur les check- lists : utilisation d’une liste préétablie et

exhaustive des risques. cette liste est fonction des activités de l’entreprise et elle

prend en compte tous les risques relatifs aux différentes activités de celle-ci.

Cependant l’entreprise doit veiller à une mise à jour permanente de cette liste pour

éviter qu’elle ne devienne obsolète ;

o Identification basée sur l’analyse historique : c’est une technique préconisé par

Barroin et Ben Salem (2002 :27) et qui consiste à partir des risques déjà survenus

dans l’entreprise dans le passé d’en tenir compte dans l’identification des risques.

o Exposure analysis : elle consiste à identifier les risques qui ont un impact sur les

actifs de l’entreprise. Les managers pour atteindre leurs objectifs utilisent les actifs

de l’entreprise qui doit de ce fait se concentrer sur les risques qui touchent à ses

actifs. Ces actifs peuvent être les moyens financiers, matériels, humains,

immatériels. Cette techniques prend en compte la taille, le type, des actifs ;




o Environnemental analysis : elle consiste en une identification des risques liés aux

activités de l’entreprise ;

o Threat scénarios : une identification des risques basée sur les fraudes et anomalie.

Plusieurs de ces techniques peuvent être combinés pour une identification exhaustive des

risques. Une fois les risques identifiés il va falloir les évaluer

2.3.1.3. Principes d’évaluation des risques de l’entreprise

L’évaluation des risques est une étape centrale du management des risques. Le résultat de

ce travail déterminera les grandes orientations du management des risques (stratégie,

politique, etc.) et constituera le socle du travail de restitution sur les risques (matrice de

criticité) de l’entreprise. :

o l’évaluation est individuelle. Il est souhaitable que les données d’évaluation soient

le produit d’une analyse personnelle.

o l’évaluation des risques n’est pas un travail de notation ou d’appréciation des

différents responsables fonctionnels ou de processus. Il faut nécessairement veiller

à ce que ce travail soit le plus objectif possible.

o l’appréciation de la probabilité est une estimation très fine des facteurs qui rendent

favorable l’apparition du risque. Il peut s’agir de facteurs internes ou externes.

L’appréciation de la gravité est une estimation très fine des impacts supposés de la

survenance du risque sur la réalisation des objectifs de l’organisation. Il conviendra de ne

pas surestimer des risques dont les impacts sur les objectifs stratégiques ne seraient que

« locaux ». De même, il faudra veiller à ne pas sous-estimer des risques.

Il est important que chaque évaluateur veille à ne pas tomber dans le piège du « biais

cognitif » c’est-à-dire la tendance à commettre des « erreurs » d’évaluation compte tenu de

facteurs subjectifs, secondaires ou erronés.

2.3.1.4. Hiérarchisation des risques

La hiérarchisation des risques se fait principalement suivant un ordre de criticité

décroissante. Pour rappel, la criticité est le produit de la probabilité d’apparition (ou

occurrence) du risque et de la gravité des conséquences du même risque (ou impact).




Elle suit les différents niveaux de déclinaison recommandés par le COSO :

o filiales;

o business unit;

o processus métiers;

o Projets.

En plus de la déclinaison suggérée par le COSO, il est loisible à chacun d’orienter son

analyse vers des niveaux d’analyses supplémentaires :

o fonctions (direction, département, service, etc.) suivant le niveau de finesse

souhaité;

o géographique;

o thème de risque;

o Etc.

La hiérarchisation des risques obéit à une logique de priorisation afin de s’assurer que

l’organisation consacre prioritairement ses ressources aux risques les plus compromettants

pour la réalisation de ses objectifs.

Elle sert principalement de base de travail pour l’élaboration du plan d’audit au sein de

l’entreprise.

2.3.1.5. Traitement des risques

Plusieurs stratégies face aux risques sont possibles, mais souvent, à un instant donné, l’une

est meilleure que l’autre, et il faut souvent combiner plusieurs approches.

Se poser régulièrement des questions sur la pertinence des stratégies retenues est un

élément clé d’une gestion efficace des risques, qui doit impliquer les opérationnels

concernés en relation avec la direction générale. Les différentes stratégies possibles sont

l’acceptation du risque, le partage du risque, l’évitement du risque, la réduction du risque.

L’acceptation du risque : l’entreprise accepte de courir le risque. Ce choix est opportun s’il

correspond à la stratégie et aux limites de tolérance définies par celle-ci, et catastrophique

s’il n’est que le résultat du hasard ou de manque d’information ;

Le partage du risque : l’entreprise considère des alliances pour partager un risque entre

divers acteurs de la chaine de valeur. Partager le risque c’est aussi le réduire en




souscrivant une assurance ou en mettant au point une joint-venture avec un tiers ce qui

revient à transférer le risque à un tiers ;

L’évitement du risque : cessation de l’activité à l’origine du risque ;

La réduction des risques : prendre des mesures nécessaires pour agir à la fois sur la

probabilité et la gravité.

2.3.2. Réalisation du travail d’audit

Les normes AFAI (2012), sur le contrôle informatique et contrôle applicatif sont intégrées

aux processus et aux services informatiques. Il s’agit dans cette partie de contrôler et de

faire des tests de conformité sur les points suivants lors du travail sur le terrain :

2.3.2.1. Sécurité informatique

Les normes AFAI (2012), définissent la gestion de la sécurité informatique au plus haut

niveau, de façon à ce que la gestion des actions de sécurité soit alignée sur les exigences

des métiers. Cela se fait par les étapes suivantes :

o le plan de sécurité informatique qui consiste à traduire les exigences des métiers,

des risques et de la conformité dans un plan global de sécurité informatique tenant

compte de l’infrastructure informatique et de la culture de la sécurité. S’assurer que

le plan se décline en politiques et procédures de sécurité assorties des

investissements appropriés en services, personnels, logiciels et matériels.

Communiquer les politiques et les procédures de sécurité aux parties prenantes et

aux utilisateurs,

o la gestion des identités consiste à s’assurer que tous les utilisateurs (internes,

externes et temporaires) et leur action sur les systèmes informatiques (applications

métiers, environnement informatique, exploitation, développement et maintenance

des systèmes) sont identifiables sans ambiguïté. Gérer les identités à l’aide de

systèmes d’authentification. S’assurer que les droits d’accès des utilisateurs aux

systèmes et aux données sont en accord avec des besoins métiers définis et

documentés et que des profils de fonctions sont attaché aux identités. S’assurer que

les droits d’accès des utilisateurs sont demandés par leur management, approuvés

par le propriétaire du système et mis en place par la personne responsable de la

sécurité. Tenir à jour les identités et les droits d’accès des utilisateurs dans un




entrepôt de données centralisé. Déployer et maintenir opérationnelles au meilleur

coût des techniques et des procédures pour créer l’identité des utilisateurs, mettre

en œuvre leur authentification et pour faire respecter les droits d’accès,

o gestion des comptes utilisateurs Disposer de procédures de gestion des comptes

utilisateurs permettant de traiter les demandes, attributions, ouvertures,

suspensions, modifications et clôtures des comptes utilisateurs et des droits

associés. Y inclure une procédure d'approbation spécifiant le nom du propriétaire

des données ou du système qui attribue les droits d'accès. Ces procédures doivent

s’appliquer à tous les utilisateurs, y compris les administrateurs (utilisateurs

privilégiés), les utilisateurs internes et externes, dans les circonstances normales ou

dans les cas d’urgence. Les droits et obligations relatifs à l’accès aux systèmes et

aux données de l’entreprise doivent faire l’objet d’accord contractuel avec tous les

types d’utilisateurs. Effectuer une revue régulière de la gestion de tous les comptes

et des privilèges associés.

o tester et surveiller de façon proactive la mise en place de la sécurité informatique.

Pour s’assurer que la sécurité informatique se maintient au niveau convenu il faut

revoir et renouveler en temps voulu sa validation. Une fonction de surveillance des

identifications doit permettre une prévention /détection rapide suivie d’un rapport

en temps voulu des activités inhabituelles/anormales qu’il peut être nécessaire de

traiter,

o définir clairement et communiquer les caractéristiques des incidents de sécurité

potentiels de façon à ce que ceux-ci soient classifiés et traités comme il convient

par le processus de gestion des incidents et des problèmes.

o protection de la technologie de sécurité,

o mettre en place des mesures de prévention, détection et neutralisation (en particulier

des correctifs de sécurité et des anti-virus à jour) dans l’ensemble de l’entreprise

pour protéger les systèmes d’information et la technologie des logiciels

malveillants (par ex. virus, vers, logiciels espion, pourriels (spam),

o mettre en œuvre des techniques de sécurité et des procédures de gestion associées

(ex. pare-feu, dispositifs de sécurité, compartimentage réseau, détection

d’intrusion) pour autoriser et contrôler les flux d’informations entre réseaux.




2.3.2.2. Sécurité des fonctions applicatives

A ce niveau il s’agit de contrôler :

o la séparation des tâches (organigramme, procédures, études et exploitation) ;

o l’adéquation des profils aux fonctions des utilisateurs ;

o les comptes utilisateurs sont-ils revus par le management ;

o les rapports d’activité sur la sécurité et la violation de la sécurité ;

o l’enregistrement et contrôle des tentatives de connexions infructueuses ;

o la politique locale de sécurité ;

o la sécurisation des accès des opérateurs ;

o la sécurité de la salle ;

o l’accès aux données, anti-virus.

2.3.2.3. Les ressources humaines informatiques

Les normes AFAI (2012), à ce niveau lors d’un audit il faut passer en revue :

o le recrutement et maintien du personnel sur les politiques et les procédures globales

de l’entreprise (ex. embauche, environnement de travail favorable, orientation).

Mettre en place des processus pour s’assurer que le personnel informatique est

déployé comme il convient dans l’entreprise et qu’il a les compétences nécessaires

pour permettre à l’entreprise d’atteindre ses objectifs ;

o vérifier régulièrement que le personnel a les compétences nécessaires pour remplir

son rôle en fonction de son instruction, formation et/ou expérience. Définir les

besoins en compétences informatiques fondamentales et vérifier qu’ils sont

satisfaits en utilisant des programmes de qualification et de certification si c’est

utile ;

o l’affectation des rôles en définissant, des référentiels pour les rôles, les

responsabilités et la rémunération du personnel, en incluant l’obligation d'adhérer

aux procédures et politiques de l'entreprise, à son code d'éthique et à ses pratiques

professionnelles. Le niveau de supervision doit être fonction de l’importance du

poste et de l’étendue des responsabilités attribuées ;




o l’orientation des employés des SI à l’embauche et leur dispenser la formation

permanente nécessaire pour tenir à jour leurs connaissances, compétences,

capacités et leur sensibilisation au contrôle interne et à la sécurité au niveau

nécessaire pour permettre à l’entreprise d’atteindre ses objectifs ;

o procédures de sécurité concernant le personnel ;

o inclure des vérifications d’antécédents dans le processus de recrutement du

personnel informatique. L’étendue et la fréquence de ces vérifications doivent être

fonction du niveau de criticité et/ou de sensibilité de la fonction et s’appliquer aux

employés, aux contractuels et aux fournisseurs.

o évaluation des performances ;

o exiger des évaluations appropriées et régulières par rapport à des objectifs

individuels établis d’après les objectifs de l’entreprise, les standards en vigueur.

2.3.2.4. Maintenance

A ce niveau il s’agit de contrôler la qualité des systèmes installés :

o faire les mises à jour majeures des systèmes existants ;

o suivre un processus de développement similaire à celui du développement de

nouveaux systèmes dans l’éventualité de modifications majeures des systèmes

existants qui ont pour conséquences des modifications significatives de conception

et/ou des fonctionnalités actuelles ;

o s’assurer que les nouvelles fonctionnalités automatisées se conforment aux

spécifications de conception, aux standards de développement et de documentation,

aux exigences de qualité et aux normes de recette. S’assurer que tous les aspects

légaux et contractuels sont identifiés et pris en compte dans les applications

développées par des tiers ;

o développer un plan d’assurance qualité, le doter de ressources et le mettre en œuvre

de façon à obtenir la qualité spécifiée dans la définition des exigences et dans les

politiques et les procédures qualité de l’entreprise ;

o au cours de la conception, du développement et de la mise en place effectuer un

suivi individuel de chaque exigence (y compris de celles qui ont été rejetées) et

approuver les modifications apportées à certaines exigences selon un processus

établi de gestion des changements ;

o développer un plan stratégique pour la maintenance des applications.




2.3.2.5. Gestion des incidents

A ce niveau il s’agit de contrôler : l’existence des procédures pour enregistrer, analyser et

résoudre les incidents.

2.3.2.6. Efficacité et efficience de la fonction informatique

A ce niveau il s’agit de contrôler :

o La gestion des moyens,

o la sécurité physique,

o l’accès aux locaux,

o gestion du parc informatique.

2.3.2.7. Help desk informatique

Selon SAWADOGO (2012), le help desk de l'entreprise est le point d’entrée unique pour

tout utilisateur qui a un problème sur sa station de travail ou sur l’utilisation des produits

qui y sont associés. Il est chargé d’accueillir les utilisateurs, de qualifier les problèmes, de

résoudre les problèmes lorsqu’ils sont de sa compétence ou d’engager la procédure

d’escalade vers les niveaux spécialisés de valider la résolution des problèmes.

Il intervention sur l’environnement PC et les périphériques associés, les outils bureautiques

inscrits au catalogue de l'Entreprise, les produits d’intérêt général (messagerie, intranet,

postes mobiles), certaines applications déployées dans le réseau.

Il s’agit de savoir si :

o l’organisation en place est-elle pertinente et optimisée ?

o la couverture des besoins, spécialisation, centralisation est effective,

o il existe des procédures couvrant toutes les activités

Le help desk doit faire l’objet de suivi pour savoir si :

o l’activité est-suivie sur la base d’indicateurs clairement définis,

o les incidents résolus,

o les indicateurs sont analysés régulièrement,




o les engagements sont-ils respectés,

o les écarts éventuels sont analysés.

2.3.2.8. Contrôle d'activité du cabinet

Les normes AFAI (2012), préconise de contrôler les indicateurs suivants :

o le délai moyen de réalisation d'une mission,

o la conformité à un référentiel identifié,

o le respect des procédures,

o la lettre de mission,

o la séparation des taches,

o la planification de la mission.

2.3.2.9. Contrôle de la performance du cabinet


o le taux d'acceptation des points d'audit ou des recommandations,

o l'avancement moyen des plans d'actions issues des recommandations,

o le budget global ou moyen par mission,

o les erreurs significatives,

o le seuil de certification,

o les réponses aux demandes de renseignement.

2.3.3. Rapport


o la préparation du rapport d'audit ;

o identifier les procédures de suivi des vérifications ;

o identifier les procédures pour évaluer et tester l'efficacité opérationnelle et

l'efficience

o identifier les procédures de test des contrôles ;

o examiner et évaluer la pertinence des documents, des politiques et des procédures.




2.3.4. Activités de suivi


o obtenir des déclarations écrites de la direction ;

o avoir une connaissance de toutes les allégations d'irrégularités ou actes illégaux ;

o communiquer irrégularités matériel / des actes illégaux ;

o envisager des mesures appropriées en cas d'incapacité de continuer à réaliser l'audit.

2.3.5. Les déterminants de la qualité de l’audit informatique

Selon les normes AFAI (2012), la qualité d’un audit est inexistante quand : les chargés de

la mission d’audit ne reconnaissent pas les besoin de sécurité informatique. Les

responsabilités opérationnelles et finales de la sécurité ne sont pas attribuées. Aucunes

mesures établies pour gérer la sécurité informatique. Il n'y a pas de rapports sur cette

question, ni de processus pour réagir aux atteintes à la sécurité informatique. Il y a une

absence totale de processus reconnaissable d'administration de la sécurité des systèmes.

Selon les normes AFAI (2012), un audit est de qualité lorsque :

o tous les processus informatiques ont été couvert lors de la mission et des

recommandations ont été formulés à l’issue de l’audit ;

o le management fait la promotion de la sécurité et le personnel commence à y être

sensibilisé. Les procédures de sécurité informatique sont définies et alignées sur la

politique de sécurité des SI. Les responsabilités dans ce domaine sont attribuées et

comprises, mais pas systématiquement exercées ;

o les responsabilités de la sécurité des SI sont clairement attribuées, gérées et

exercées. On analyse régulièrement les risques informatiques et leurs

conséquences. On complète les politiques et les procédures de sécurité par des

principes de base spécifiques à la sécurité. On rend obligatoire les méthodes pour

promouvoir la sensibilisation à la sécurité. On a standardisé l'identification des

utilisateurs, leur authentification, et leurs droits d'accès ;

o la sécurité des SI est sous la responsabilité conjointe des responsables métiers et

informatique, et elle fait partie des objectifs de sécurité de l'entreprise. Les

exigences de sécurité informatique sont clairement définies, optimisées, et incluses




dans un plan de sécurité approuvé. Les utilisateurs et les clients sont de plus en plus

responsables de la définition des exigences de sécurité, et les fonctions de sécurité

sont intégrées aux applications dès la conception. le plan de sécurité selon un

processus d’amélioration continue.

2.4. La présentation, l’analyse des résultats et les recommandations

Il s’agit ici de présenter les résultats issus de notre étude.

2.4.1. La présentation des résultats

Selon YAZI (2009), dans sa publication sur la méthodologie de rédaction de mémoire, il

faut présenter les résultats issus d’une étude de la manière suivante :

o suivre un ordre logique découlant d’un bon plan de présentation des résultats;

o ne doit pas être une présentation alignée des variables du modèle.

Les résultats doivent être pertinents par rapport à:

o aux problèmes étudiés;

o les objectifs de recherche;

o les variables et les relations du modèle d’analyse.

Il faut illustrer, autant que faire se peut, la présentation par des tableaux et/ou des figures.

2.4.2. L’analyse des résultats

Pour YAZI (2009) il faut analyser les résultats de la façon suivante :

o expliquer et commenter les principaux résultats issus de l’étude;

o l’analyse peut se faire au fur et à mesure de la présentation des résultats ou

séparément;

o utiliser les outils informatiques;

YAZI (2009), nous apprend qu’il faut avoir un bon plan d’analyse des résultats, avec

comme référence:

o les questions de recherche;




o le modèle d’analyse;

o la revue de littérature;

o les hypothèses de recherche.

2.4.3. Les recommandations :

Elles peuvent porter sur:

o les faiblesses, les conséquences et les risques découlant de l’étude;

o les problèmes décelés par l’étude;

o la mise en œuvre de nouveaux outils.

Elles sont adressées à des acteurs qui en sont concernés et qui peuvent influencer leur mise

en œuvre. La mise en œuvre de ces recommandations doit faire l’objet d’un plan d’action

ou plan de mise en œuvre.

Conclusion Chapitre 2

Notre méthodologie de l’évaluation de la qualité d’une mission d’audit étant mise en place

nous allons dans le chapitre suivant mettre en place notre approche méthodologique qui va

nous aider à réaliser notre travail.




CHAPITRE 3 : APPROCHE METHODOLOGIQUE

Pour organiser cette évaluation nous allons adopter une méthodologie de la recherche qui

va orienter notre étude.

Apres avoir présenté le référentiel d’évaluation de la qualité, il nous semble opportun de

présenter notre modèle d’analyse qui découle de la méthodologie d’évaluation d’une

mission d’audit. Il faut aussi dire que cette évaluation permettra au cabinet d’améliorer ces

missions d’audit dans un avenir proche. La revue de littérature effectuée jusque-là nous

permettra de construire notre modèle d’analyse.

L’approche méthodologique se fera par la construction du modèle d’analyse et ensuite par

la description des outils qui nous permettront d’évaluer la qualité de notre mission d’audit.

3.1. Modèle d’analyse

Le modèle d’analyse que nous proposons est conçu à partir de la synthèse de nos lectures

sur le thème de notre étude. Il est le lien entre la partie théorique et la partie pratique de ce

mémoire et le résumé de la démarche de notre travail. Notre démarche comprend quatre

phases que nous détaillerons dans la figure du modèle d’analyse comprenant :

o la conduite de la mission d’audit ;

o l’évaluation de la qualité de la mission;

o l’analyse des résultats ;

o les recommandations.




Figure 1 : Schéma du modèle d’analyse

Phases Etapes Outils

Recommandations

Source : nous-mêmes.

-Planification

Conduite de

la mission

d’audit

informatique

-Documentation

Evaluation

de la qualité

de la mission

d’audit

informatique

Evaluation des indicateurs de la

qualité d’une mission

Présentation

des résultats Analyse des résultats de

l’évaluation

Plan d’actions

-Méthode analytique

-Documentation

- Entretien

-Examen analytique

-Observation

-Réunion d'ouverture

-Réalisation du travail d’audit

-Entretien d’audit -Documentation -Observation directe et physique -Questionnaire -Grille d’analyse de contrôle interne

-Compte rendu final -rapport d’audit - Activité de suivi

- Documentation

- Entretien




3.2. Méthode de collectes de données d’une mission d’audit informatique

Nous allons décrire dans cette partie la collecte de données sur le terrain. Les outils de

collecte de l’information les plus utilisés, tout au long de la mission sont les suivants :

o l’entretien d’audit ;

o l’observation physique ;

o les questionnaires ;

o grilles d’analyse de contrôle interne ;

o la documentation ;

o la méthode analytique.

3.2.1. L’entretien d’audit

Elle consiste en une conversation avec les responsables des cellules informatiques sur la

base d'un guide d'entretien. Il s'agit pour nous de connaître les étapes des procédures en

interrogeant les différents interlocuteurs sur les moindres détails concernant la réalisation

de leurs tâches au sein du MEF. COHEN (2006 : 24) affirme « qu’il faut détecter les

fonctions conflictuelles inter SI ou intra SI pour éviter le ralentissement des processus ».

3.2.2. L’observation directe et l’observation physique

Cette technique sera utilisée pour voir réellement ce qui se passe au sein des différentes

structures de la direction informatique pendant la réalisation de l’audit. L’entretien n’est

pas suffisant pour bien comprendre les procédures étudiées. Il faut consulter toute la

documentation du ministère. L’observation nous permet aussi d’apprécier les la qualité des

structures qui nous accueillent.

Par ailleurs, l’observation directe nous a permis de soulever des problèmes qui ne sont pas

connus du MEF.

3.2.3. Le questionnaire

Les questionnaires servent d'étalon. Ils permettent, grâce à un grand nombre

d'interrogations précises, d'évaluer si les procédures de l'entreprise auditée remplissent les

objectifs fondamentaux du contrôle interne, en décelant ses forces et ses faiblesses. Les

questionnaires se présentent habituellement sous deux formes : l'une simplifiée qui ne




motive pas d'autres réponses que le oui ou le non, est appelée questionnaires fermés, et

l'autre plus complète, qui entraîne nécessairement des observations détaillées, est

dénommé. Les questionnaires sont établis à l'aide de guides opératoires afin qu'aucune

question essentielle ne soit omise.

3.2.4. Les grilles d'analyse de contrôle interne

Les grilles d'analyses de contrôle interne servent à détecter les cumuls de fonction. Il s'agit

des tableaux à double entrée qui permettent de décomposer la procédure en différentes

opérations assumées par les agents informatiques du MEF. Dans la démarche de l'auditeur,

cette étape revient à identifier les forces et les faiblesses de la fonction auditée.

Cette évaluation peut se faire dans un rapport de synthèse, précisant l'impact des faiblesses

sur la production de la fonction informatique.

3.2.5. La documentation :

Elle est basée sur la documentation disponible au MEF. Il s’agit des documents comme les

anciens rapports d’audit informatique, audit des systèmes d’information, les documents

émanant de la bibliothèque du cabinet, les normes ISACA, les rapports d’audit

précédemment effectués par le cabinet qui nous accueille etc.

3.2.6. La méthode analytique :

Cette méthode nous a permis d’analyser les résultats issus de l’évaluation de la qualité de

notre mission d’audit.

Conclusion

Ce chapitre nous a permis de dégager les grandes lignes qui nous permettront d’élaborer la

partie pratique de notre étude. Nous avons enfin défini les différents critères qui nous

permettront d’évaluer la qualité de notre mission d’audit à partir du modèle d’analyse mis

en place qui est le lien entre les deux parties.




Conclusion de la première partie

L’évaluation de la qualité d’une mission d’audit n’est pas une tâche aisée compte tenu de la

difficulté du choix des indicateurs. La méthode d’évaluation développée dans la première

partie devrait faciliter cette tâche. Nous avons ainsi mis en exergue le déroulement d’une

mission d’audit ensuite les indicateurs de qualité. Le modèle d’analyse qui est le lien entre

la première et la seconde partie vient clore la partie théorique. Cette partie clos trois

chapitres théoriquement développés pour nous permettre d’aborder la seconde partie.

Apres avoir mis sur pied notre modèle d’analyse, nous sommes en mesure d’évaluer la

qualité de notre mission d’audit.


DEUXIEME PARTIE : CADRE PRATIQUE




Le travail théorique terminé, nous aborderons dans cette partie les aspects pratiques du

travail. Le premier chapitre de cette partie sera consacré au cabinet Qualisys Consulting,

où nous verrons son organisation, son fonctionnement et sa structure.

Un deuxième chapitre sera consacré à l’évaluation de la qualité de la mission d’audit

informatique, notamment les aspects positifs et négatifs. Cette partie est importante

puisqu’elle fera le rapprochement avec les hypothèses théoriques de la première partie.

Un troisième chapitre présentera les résultats observés et en fera une analyse avant de

proposer des améliorations ainsi que les mises en œuvre.




CHAPITRE 4 : PRESENTATION DU CABINET QUALISYS CONSULTING

Une présentation du cabinet permettra de connaitre ses différents départements qui

définissent son mode de fonctionnement, sa mission et ses objectifs. Ainsi donc une revue

globale du cabinet sera effectuée.

4.1. Historique du Cabinet

QUALISYS CONSULTING est un Cabinet de Système d’Information qui s’est implanté

sur le marché sénégalais voilà bientôt 10 ans. Il a été crée pour proposer ses compétences

en termes de services (Conseil, Assistance, Etude et Audit des SI) et en termes de

formations auprès des maîtrises d’œuvres des systèmes d’informations11. Ces locaux se

trouvent a sacré cœur en face de l’observatoire de la qualité des services financiers

sénégalais.

Etant donné que plusieurs cabinets offrent les mêmes produits sur le marché, et l’état de la

concurrence actuelle fait que pour atteindre ses objectifs qu’il s’est fixé c’est-à-dire devenir

le premier cabinet dans son domaine, le cabinet Qualisys consulting opte pour une qualité

de service. Il s’emploie à mettre à jour les compétences de ses membres à travers des

formations continues. Afin de répondre aux nouvelles exigences des clients, ils proposent

des prestations d’accompagnement global allant de la mise en place des principes de

Gouvernance d’entreprise à l’optimisation des processus métiers et l’adoption des

meilleures pratiques en matière de systèmes d’information et de management de projet.

Les prestations d’accompagnement global s’articulent autour de 5 pôles de service :

o Système d’Information, Assistance MOE, Assistance MOA ;

o gouvernance Informatique, bonne pratique IT12 et sécurité de l’information ;

11 Le terme maîtrise d'œuvre (souvent abrégé MOE ou MŒ ou Moe) désigne une personne ou entité

(dénommée maître d'œuvre ou parfois l'entrepreneur) chargée de la conception puis de la conduite

opérationnelle de travaux généralement pour le compte d'autrui. 12 La Gouvernance des Systèmes d'Information ou Gouvernance informatique (en anglais « IT gouvernance

») renvoie aux moyens de gestion et de régulation des Systèmes d'Information (SI) mis en place dans une

entreprise pour atteindre ses objectifs. A ce titre, la gouvernance IT fait partie intégrante de la gouvernance

d'entreprise.




o modélisation, cartographie et Business process Management ;

o management des projets ;

o développement et intégration de solutions.

4.2. Mission et Objectifs

Décrivons la mission et les objectifs du cabinet :

4.2.1. Mission

Acteur majeur du conseil en système d’information et organisation IT, QUALISYS

Consulting s’est donné pour mission de devenir un cabinet leader dans son domaine malgré

un marché miné par une concurrence accrue. Il tient à garantir à ses clients un travail

soigné dans un esprit de professionnalisme.

4.2.2. Objectifs

Les consultants s'engagent dans un processus de formation spécifique dans le domaine du

conseil, basé sur un apprentissage théorique et sur la mise en pratique de méthodes et

d'outils éprouvés au sein des organisations.

Au niveau de la neutralité et des bonnes pratiques des prestations de conseil, les

consultants QUALISYS démontrent leur professionnalisme en respectant les conditions

suivantes : les étapes et livrables sont bien mentionnés (en avant-projet), les charges pour

le consultant et l’entreprise sont mentionnées (en avant-projet), le tarif journalier

applicable et le montant global de la prestation sont mentionnés (en avant-projet), le

planning indicatif est indiqué (en avant-projet), chaque étape donne lieu à un livrable

(résultat produit) formel.

A travers son équipe de consultants expérimentés et certifiés dans ses domaines de

compétences, QUALISYS CONSULTING accompagne ses clients pour l’adoption des

meilleures pratiques.

4.3. Organisation du cabinet

Le cabinet est organisé de la façon suivante :




o administration : le cabinet est administré par un directeur général qui est aussi

l’administrateur gérant. Il définit la politique générale du cabinet et surveille ses

activités à tous les niveaux.

o moyens humains : depuis sa création le cabinet a beaucoup évolué. Il emploie

actuellement cinq consultants seniors appuyés par des stagiaires. Il y’a aussi des

externes lors des formations pour les préparations des certifications.

o moyens matériels : le cabinet dispose de vastes locaux sis sacré cœur qui comprend

les bureaux, une salle de conférence moderne pour les réunions et la préparation

des audits et des certifications.

4.3.1. Structure opérationnelle

Le cabinet est composé comme suit :

o Direction Générale : qui est le gérant du cabinet, il s’occupe de sa bonne marche. Il

s’occupe de tous les projets d’envergure. C’est par ailleurs un consultant senior qui

prépare les audits et intervient lors des formations certifiantes au sein du cabinet.

o le Secrétariat de Direction : géré par une secrétaire qui a pour missions d'assurer la

communication dans l'entreprise, de recevoir toutes les correspondances et les

transmettre au Directeur Général, de la rédaction des correspondances que le

cabinet envoi à ses partenaires, et établit les factures pro formas et définitives.

o Département Administration : s’occupe de l’administration, de la comptabilité, de

l’informatique et des services.

o Département Information : il s’occupe de préparer les formations dispensées par le

cabinet. Il est composé de consultants principalement. Ces formations ont souvent

lieu dans les locaux du cabinet ou dans les entreprises qui désirent former ces

cadres ou les certifiés dans certains domaines comme la gestion de projets.

o Département Technique : ce département est celui qui prépare les audits. Il aide

aussi les entreprises à s’équiper d'un nouvel outil informatique ou au moins d'en

étudier l'opportunité pour l'atteinte de leurs objectifs métiers. Il prépare l’assistance

à l’étude amont et aux spécifications, étude d’opportunité et cadrage de projets,

étude du positionnement du projet (objectifs et enjeux, périmètre, situation au sein

du SI, place dans un schéma directeur), description et Analyse critique de

l’existant, définition des scénarios, analyse économique.


http://www.meublesdoudard.fr/secretaire.html



o département commercial : il est chargé de vendre l’image du cabinet auprès des

entreprises de la place désireuse de former ses cadres dans certains domaines. Il le

fait à travers des journées porte ouverte au cabinet pour montrer l’importance des

formations proposées.

Voir organigramme (annexe I page)

4.3.2. Le département technique

C’est le département qui nous accueille durant notre stage. Il est composé principalement

de consultants senior chargé de préparé les missions d’audit et les formations en externe

auprès des entreprises. Il est chargé de préparé et de mettre en place un système

d'information et de communication adéquat pour les entreprises. Il participe fortement à

l'amélioration des performances administratives et commerciales des entreprises.

Les Consultants spécialistes en système d'information et en technologies de l'information et

de communication interviennent en tant qu'experts et conseils pour permettre aux

entreprises la conception de leur système d'information.

4.3.3. Les différents secteurs d’activités ou le cabinet intervient

Le cabinet qualisys consulting intervient dans les secteurs d’activités suivant :

o les télécommunications : le cabinet aide ses clients comme orange Sénégal à

s'adapter aux changements, capitaliser sur leur connaissance et optimiser leur

processus. Les consultants accompagnent les entreprises dans le développement de

solutions pour saisir les opportunités de marché. Le cabinet dispose d’une bonne

connaissance du secteur des télécommunications, en mesure de comprendre les

problématiques et de proposer des services adaptés comme : documentation du

système de contrôle interne cartographie des processus et des risques, maîtrise des

systèmes de calculs des coûts de communication,

o pétrole et énergie : audit contractuel dans l’amont et l’aval pétrolier pour des

sociétés, ou des organismes internationaux en Afrique,

o accompagnement dans la réorganisation et externalisation de l’audit interne,




4.3.4. Différents types d’audit réalisé par le cabinet

Le cabinet Qualisys consulting réalise les audits suivants :

o audit informatique ;

o audit stratégique ;

o audit du schéma directeur ;

o audit des coûts informatiques ;

o audit de la gestion d’un réseau ;

o audit opérationnel.

Conclusion chapitre 4

Ce chapitre clos la présentation de l’entreprise, ses missions, ses objectifs ainsi que son

mode de fonctionnement. Le cabinet Qualisys est un cabinet certes jeune mais en pleine

phase de croissance qui tient à s’octroyer une grande part de marché dans son domaine. Ses

consultants sont très dynamiques et ne pensent qu’à offrir a leurs clients des prestations de

qualité selon les standards internationaux afin de les fidéliser.




CHAPITRE 5 : EVALUATION DE LA QUALITE DE LA MISSION D’AUDIT

INFORMATIQUE.

Au cours du stage effectué au sein du cabinet Qualisys consulting, nous avons eu

l’occasion de participer à une mission d’audit informatique. Le Ministère de l’Economie et

des Finances, conscient de l’importance d’une structure informatique dans la mobilisation

d’une partie des ressources de l’état compte jauger le niveau de sécurité de celui-ci. Il a été

commandité par le MEF dans le but d’évaluer l’organisation de sa fonction informatique.

Comme l’as écrit BOMBAL (2006 : 10) « l’important pour l’auditeur est bien entendu

d’arriver à faire exprimer les attentes du commanditaire ».

L’acquisition de nouveaux logiciels sans aucune forme de normalisation (sources non

auditées, non certifiées), la croissance exponentielle du parc informatique des ordinateurs

ainsi que la prolifération de nouvelles menaces (virus, hacking,…) démontrent aujourd’hui

que la sécurité est un enjeu stratégique majeur.

Ainsi, le projet d’audit doit couvrir tous les aspects de la fonction informatique ainsi que

l’audit physique du parc informatique.

La mission d’audit a débuté en janvier et s’est clôturé en février 2012, soit plus d’un

bimestre, au sein des locaux du ministère de l’Economie. Le travail s’est fait

essentiellement sur la base d’entretien avec les différents agents, des tests et du contrôle du

parc informatique.

La mission d’audit réalisé par le cabinet Qualisys s’est fait par une équipe de 4 auditeurs

des SI qualifiés et des auditeurs stagiaires. Les principaux consultants avaient les profils

suivants : le chef de projet (CDP) qui est le directeur général du cabinet. C’est un

informaticien spécialiste en sécurité SI puis il y’avait des informaticiens spécialisés en

système principal, en Réseau & Télécoms, assurance qualité, en organisation, ainsi que les

stagiaires du cabinet.




5.1. Evaluation de la planification de la mission

Au cours de cette mission les documents suivants ont été consultés :

o rapport des précédents audits informatique qui date de 2 ans car les activités de

contrôle et d'audit des SI restent très insuffisantes et pas encore systématisées au

sein des structures du MEF, il ne possède pas d’entité formelle et les ressources

adéquates (humaines, techniques et méthodologiques) nécessaires à l'audit interne

des SI. Il n’existe pas de plans de contrôle permanent adaptés au regard de

l'évolution des pratiques, des risques et plus généralement des SI. Les audits

indépendants ne sont pas réalisés régulièrement;

o fiche de poste des différents responsables des services informatiques.

Les activités de contrôle ont portés principalement :

1. sur le parc informatique :

o états des machines : fonctionnels ou non ;

o sécurité des machines : protégé ou non par un mot de passe ;

o logiciel utilisé ;

o écart entre le nombre de machine présente physiquement et le nombre de

machine répertorié sur le bordereau de contrôle ;

o le nombre de postes de travail fixes et mobiles ;

o les serveurs ;

o les applications bureautiques ou métiers ;

o les moyens de connexion à Internet et multi-sites ;

o la sécurité des données et de l'accès au réseau.

Nous notons l’absence d’une politique uniforme de gestion des supports informatiques de

données et programmes. En effet, aucune politique n’est définie relative à la question des

supports amovibles personnels (clé USB, CD-R, Smartphones,…) ainsi que pour les

médias d’installation des programmes/progiciels

2. Sur les fiches de postes de chaque agent avec l’aide d’une grille d’analyse de

contrôle interne pour détecter tout cumul de fonction :




o mise à jour ;

o identification du poste ;

o identité de l’agent ;

o présentation du service ;

o mission du poste ;

o compétence requises ;

o objectifs du poste.

3. Sur les locaux :

o existence des portes coupe-feu

o bonne aération

o branchement électrique sécurisé

o présence des onduleurs pour protéger les données en cas de coupure

4. sur l’organisation de la fonction informatique :

o en s’assurant qu’aucun rôle n’est attribué en double ou en recouvrement ;

o en vérifiant que l’ensemble des rôles affectés à l’organisation est effectivement

pris en charge dans l’organigramme ;

o que chaque poste est utilisé de façon optimale.

Cette phase a duré trois jours, puis une prise de connaissance générale des locaux a été

entreprise.

Recherche de la documentation et entretiens préparatoires :

o entretiens : ils ont été effectués avec tous les agents pour les édifier sur l’objet de la

mission et recueillir leur avis. c’était aussi l’occasion de savoir s’ils se posaient des

questions particulières sur certains points de l’audit. chaque entretient élaboré est

classé dans un dossier de travail.

o recherche documentaire : une prise de connaissance de l’organigramme de l’entité a

été effectuée. Nous avons consulté les différentes fiches de poste ainsi que la

documentation interne. Des statiques sur l’évolution de la fonction informatique en

été effectué. Nous avons porté un regard sur la provenance des logiciels et systèmes

d’exploitation utilisés.




C’est à la suite de cette phase que les auditeurs ont pu de déterminer des actes

d’investigation. Par la suite nous avons rédigés une note de cadrage :

Note de cadrage de la mission :

o entretien avec les responsables des services informatiques (présentation, objet de la

mission et sa durée)

o s’assurer de l’existence d’un organigramme à jour (mis à jour récente)

o s’assurer de l’existence de fiche de poste à jour pour chaque agent

o faire l’inventaire physique du parc informatique

o s’assurer de la clarté des structures et des responsabilités de l'équipe informatique,

o la définition des relations entre la direction générale, les directions fonctionnelles et

opérationnelles et la fonction informatique,

o l'existence de dispositifs de mesures de l'activité et notamment d'un tableau de bord

de la fonction informatique,

o le niveau des compétences et des qualifications du personnel de chaque fonction.

o s’assurer de l’existence de manuel de procédure à jour pour chaque mission

o validation des pré-constats avec les audités

o rédaction du rapport

La note de cadrage a été rédigée par le chef de mission et conserver dans le dossier du

travail.

5.1.1. Aspect positif de l’évaluation

Toute la documentation a été consultée lors de la planification de la mission d’audit. Les

auditeurs ont procédé par une vérification de l’état des lieux du MEF. Conformité de la

mission au référentiel dicté par l’ISACA.

5.1.2. Aspect négatif de l’évaluation

Lors de la mission l’approche par les risques n’a pas été effectuée. Le cabinet s’est

contenté d’une précédente cartographie des risques lors d’un audit effectué au ministère.

Les situations évoluent, comme le recommande les normes AFAI(2012), à chaque mission

doit correspondre une nouvelle approche des risques qui doit comprendre les étapes

suivantes :




o identification des risques informatiques ;

o hiérarchisation des risques informatiques ;

o évaluation des risques informatiques ;

o traitement des risques informatiques ;

o existence d’un plan d’actions contre les risques informatiques.

Notons aussi que le délai moyen de réalisation de la mission d’audit n’a pas été respecté.

5.2. Evaluation de la réunion d'ouverture

La réunion d'ouverture s’est tenue entre les auditeurs et les responsables de la structure qui

accueille la mission. Chaque auditeur a été présenté par le chef de mission. C’était

l’occasion de prendre connaissance de l’organigramme de la structure, de ses locaux, des

fiches de postes ainsi que de la responsabilité de chaque agent (attributions et taches a

effectués).

Le directeur a été informé des modalités d’investigations (déroulement de la mission et

débriefing).


Tous les responsables du MEF étaient présents lors de la réunion d’ouverture.


Le plan de communication a été mal structuré. Il aura fallu plusieurs rappels pour voir les

responsables des structures informatiques présentes lors de la réunion d’ouverture. Cela

s’explique peut-être par la période électorale13 qui prévoyait lors de l’audit en 2012.

5.3. Evaluation de la réalisation du travail d’audit

Actuellement au sein du MEF, il existe des services informatiques à différents niveaux de

la hiérarchie avec en général des difficultés de positionnement, une insuffisance dans

13 Pendant la campagne présidentielle de 2012 au Sénégal, il y’avait des mouvements de violences opposant les forces de l’ordre aux manifestants du M23.




l’utilisation de formalisme et de standardisation ainsi que dans la coordination des actions

informatiques

A l’aide d’entretiens avec chaque agent, de visites de locaux et d’examens de la

documentation disponible, nous établissons la description des services informatiques ainsi

que la situation actuelle des systèmes d’informations. Les rôles et responsabilités liés à la

sécurité de l’information ne sont pas encore clairement définis au sein du MEF et de ses

Directions. La séparation des fonctions n’est pas effective. Certains informaticiens jouent

aussi le rôle de maintenancier.

Vu l’inexistence actuelle d’unité de reporting et de gestion des incidents, le manque

d’organisation formelle des audits internes lié à la sécurité, l’absence d’unité ou d’instance

de gestion de crise liée à la sécurité de l’information la défaillance au niveau de la

répartition des fonctions

Nous conduisons également des entretiens spécifiques orientés vers la technique en

examinant les configurations des bases de données des applications métiers et l’évaluation

des plans de sauvegarde et de secours informatique. Cette démarche nous permet de

formuler globalement une opinion sur la gouvernance des SI.

Les travaux nécessaires à l’élaboration de cette description nous ont permis de comprendre

et d’analyser les processus clés ainsi que les applications métiers qui traitent les

transactions.

L’inexistence de procédure informatique formalisée relative à la sécurité peut engendrer

des difficultés de la mise à jour des applications informatiques, l’absence de formation et

de sensibilisation des utilisateurs, absence d’un guide de sécurité aux utilisateurs.

Nous relevons les supports procéduraux utilisés dans l’activité de la production

informatique et dans la gestion de la maintenance applicative et des infrastructures

techniques. Ces travaux de prise de connaissance et de description de l’existant ainsi que

l’examen des pratiques actuelles des agents en charge de la gestion des applications nous

permettent d’établir des constats et de les qualifier en nature et gravité.

L’essentiel des applications est développé par des prestataires externes. Cependant, nous

constatons, d’une part, que les conventions entre le prestataire et les directions




informatiques ne sont toujours pas assez claires et ne définissent pas entièrement les règles

et obligations de toutes les parties, d’autre part, que les contrats de maintenance ne sont

pas spécifiquement signés avec ces fournisseurs pour les logiciels et progiciels requérant

une forte disponibilité.

La gestion des versions des sources des applications obtenues des fournisseurs ne fait pas

non plus l’objet d’une procédure formelle (ou ces dernières sont placées en fiducie).

Parallèlement à cela, notre équipe conduit des tests à l’aide d’outils spécialisés pour

l’audit.

La qualité de l’organisation générale de la fonction informatique dépend essentiellement de

principaux facteurs : le positionnement de la fonction informatique, la séparation des

fonctions et la gestion du personnel informatique. L’organigramme du système

d’information a été consulté. L’existence de procédures de suivi fournit un avantage très

important pour le bien de l’entreprise car ces procédures permettent : l’évaluation du

patrimoine existant, le suivi de la situation actuelle. L’existence de politiques, de normes et

de procédures a été vérifiée. Cela permet de savoir si les procédures informatiques

permettent de justifier que la fonction informatique est bien organisée et qu’elle respecte

les règles de travail, et ce afin d’avoir un service de qualité et bien développé.

Chaque direction peut suivre des fiches techniques ou des manuels de politique, de norme

et de procédures servant à la planification, à l’organisation, au contrôle et à l’évaluation de

la direction informatique concernant les normes de management de la sécurité du système

informatique, les procédures par la mise à jour des applications informatiques et

l’élaboration d’un guide de sécurité aux utilisateurs.

Les informaticiens en charge des tâches d’exploitation ne sont soumis à aucune disposition

particulière liée à ces tâches. Il n’existe aucune politique de sécurité qui garantit la

protection de l’information, des biens et empêche de procéder à des comportements

interdits.

Comme illustration, toutes les nouvelles recrues (informaticiens) jusqu’à ce jour ne sont

pas réellement affectés à leurs tâches dans le cadre d’une procédure administrative

adéquate.




L’accès aux outils et utilitaires d’administration des systèmes d’exploitation et base de

données n’est pas contrôlé par des mécanismes documentés.

Les conditions d'accès du personnel informatique aux informations sensibles ou

confidentielles ne sont pas clairement définies dans le cadre de leurs activités quotidiennes

d’administration et d’exploitation.

Les procédures de surveillance des systèmes dans le cadre de l’exploitation ne sont pas

formalisées. Les administrateurs ne produisent aucun rapport périodique obligatoire

pouvant rendre compte fidèlement la nature de leur intervention et de l’état du système.

L’inexistence de méthode d’évaluation des risques et de la gestion de la sécurité

informatique a pour conséquence : le non garanti de l’harmonisation et de la qualité de

l’application, difficulté d’évaluation du personnel informatique. Nous avons aussi constaté

l’inexistence de procédure informatique formalisée relative à la sécurité. Cela peut

engendrer : des difficultés de la mise à jour des applications informatiques, une absence de

formation et de sensibilisation des utilisateurs.

L’application des normes de management de la sécurité du système informatique a été

vérifiée. En effet elles ne sont pas appliquées comme correctement.

Aucune liste n’est formellement préparée consignant les détenteurs des actifs

informationnels responsables de leur catégorisation, des autorisations d'utilisation et des

mesures de protection des données. Il faudrait mettre en place un processus d’identification

et catégorisation des actifs conformément à la norme ISO 2700114, les directions doivent

déterminer le degré d'importance et de délicatesse de leur information et de leurs actifs sur

les plans de la confidentialité, de l'intégrité, de la disponibilité et de la valeur.

La gestion des risques de sécurité informatique n'est pas encore formalisée ainsi que

l’approche de cartographie des risques SI n’est pas encore suffisamment développée en

interne. Aucune analyse formelle des risques de la sécurité des SI n’est effectuée au sein

14 L'ISO/CEI 27001 est une norme internationale de système de gestion de la sécurité de l'information, publiée en octobre 2005 par l'ISO dont le titre est Technologies de l'information - Techniques de sécurité - Systèmes de gestion de sécurité de l'information - Exigences.




des structures du MEF. Un mécanisme doit être mis en place afin d’évaluer

périodiquement les risques et menaces pouvant affecter les actifs informationnels de

l’organisme. Le MEF devra se baser sur la norme ISO 2700515 et une méthodologie

comme EBIOS.

Après avoir constaté l’absence de procédures pour répondre rapidement et efficacement

aux incidents de sécurité et le non reporting des signalisations des évènements de la

sécurité de l’information nous avons préconisés la mise en place d’un système de suivi et

de rapport des incidents. Le MEF doit d’une part formaliser le processus de

communication lié à la gestion des incidents.

La responsabilité des directions informatiques au sein de l’organigramme générale du

ministère a aussi fait l’objet d’un test. Nous avons essayé de définir clairement les

responsabilités des directions informatiques ses pouvoirs et son rôle moteur dans la

circulation de l’information. Une vérification de la séparation effective des fonctions des

responsables informatiques a été faite pour éviter que l’accumulation des fonctions ne se

fasse.

Les tâches ne sont pas clairement séparées entre le personnel de développement, de

maintenance et d’exploitation.

Il n’est pas possible d’effectuer le contrôle de l’exploitation car il y’a une absence totale de

procédure formelle d’exploitation des applications.

Le personnel technique effectue ces tâches sur la base de documents techniques, parfois

des guides d’utilisateurs, ou alors sur un ensemble de scripts permettant d’effectuer les

tâches pour le bon fonctionnement du système. Mais il est clair que les modes opératoires

ne sont pas explicitement rédigés pour garantir la continuité.

Aucun calendrier des tâches formelles n’est préparé en fonction des besoins d’exploitation.

15L'Organisation internationale de normalisation a publié, le 4 juin 2008, la première norme de gestion des risques de la Sécurité des Systèmes d'Information : l'ISO/CEI 27005:2008. Cette norme est un standard international qui décrit le Système de Management des risques liés à la Sécurité de l'information.




Les activités effectuées par les opérateurs ne sont pas journalisées et révisées

périodiquement.

Il y’a absence d’engagements du personnel aucune procédure pour la gestion du personnel

et des partenaires stratégiques. Il faudrait améliorer la GRH de la fonction informatique en

réponse aux constats relatifs au déficit de compétences du MEF sur des sujets critiques, il

est recommandé de travailler sur la dimension RH de la fonction informatique.

Il faut mettre en place un certains nombres de mécanismes adéquats relatifs à la sécurité

de l’information au cours des différents programmes mis en œuvre durant le cycle de vie

des employés dans l’institution: programme d’accueil des employés ; programme de

mutation ou de départ des employés ; programme de recrutement des employés.

Le contrôle des achats informatiques a démontré que les achats se font à partir de bons

d’achat délivré par la direction financière pour plus de sécurité.

Un inventaire des équipements informatiques a été initié à partir du cinquième jour. Nous

avons vérifié :

o le nombre d’unités centrales (postes fixes), de références Dell, HP dotés de

processeur dual core ;

o le nombre des postes mobiles ou laptops ;

o les différents postes de travail sont interconnectés en réseau via des Switch et des

hubs ;

o le câblage Informatique qui est assez vétuste au moment des contrôles ;

o les boitiers des prises muraux sont repérés par des étiquettes portant un numéro

unique sur le réseau et qui est repéré facilement dans le panneau de brassage pour

l’interconnexion avec les commutateurs.

o les imprimantes : il en existe trois en excellent état dans toute la direction

o les défauts de climatisation : la salle hébergeant le matériel informatique (serveurs,

modem) n’est pas climatisée

o l’absence d’un détecteur contre l’humidité et les dégâts d’eau

o l’échange de données échangées par le personnel (niveau de confidentialité)




o virus : la majorité des postes de travail disposent d’un antivirus installé (Kaspersky)

qui vérifie en permanence les fichiers de l’ordinateur, mais il y’a quelques un qui

sont mal configurés et qui ont une mise à jour ancienne

o les risques humains : les risques de malveillance, les risques de maladresse et

d’inconscience des utilisateurs, effacer involontairement les données ou des

programmes.

Par la suite nous avons consulté les fiches de postes pour établir les constats par la suite.

L’élaboration des pré-constats a été effectuée à partir des entretiens que l’équipe avait

menés, de la documentation qu’elle avait exploités, des contrôles techniques, de l’audit

physique. Pour éviter des possibles contestations des entretiens croisés ont été effectués

avec plusieurs agents. En cela les pré-constats portaient sur :

o le contrôle de l’existant;

o contrôle des différentes fiches de postes ;

o le contrôle des manuels de procédures ;

o l’organisation de la production informatique.

Le chef de mission réunissait tous les auditeurs avant la décente. C’était l’occasion pour lui

de faire le point sur l’état d’avancement des travaux. Lorsqu’il y’avait des zones d’ombres

pour certains membres de l’équipe il s’arrangeait a les éclaircir. C’est à ce moment-là que

les auditeurs lui faisaient part des difficultés rencontrées.

Le dossier de travail contenait tous les entretiens, l’examen de la documentation et les pré-

constats. Il doit constituer la base de la rédaction de notre rapport d’audit. Ce dossier peut

aussi servir de preuves d’audit en cas de contestation des résultats par les audités. Apres

chaque mission il est archivé au niveau du cabinet.

5.3.1. Aspect positif de l’évaluation :

Les tests de conformité sur la sécurité informatique ont été effectués qui ont portés entre

autre sur l’évaluation des risques de la sécurité, l’évaluation des mécanismes

d’authentification, la vérification la procédure de gestion des comptes utilisateurs,

l’évaluation de la procédure de création/modification/suppression des droits d’accès.




Toutes les fonctions applicatives ont fait l’objet de test sauf que les données rejetées ne

font pas l’objet de conservation.

Le test sur le contrôle des ressources humaines informatiques ont porté sur la séparation

des tâches, l’évaluation des compétences, de l’expérience et de la formation du personnel

informatique, l’évaluation de l’affectation des rôles, la mise à jour des connaissances au

contrôle interne des procédures de sécurité concernant le personnel. La fonction ressource

humaine informatique a été contrôlée lors de notre audit, sauf que pour les prochains

audits, le cabinet devrait évaluer l’orientation des employés des systèmes d’informations à

l’embauche.

Les tests ont aussi portés sur la maintenance pour vérifier l’accès aux bibliothèques de

production interdit aux analystes programmeurs, la qualité des systèmes installés, le

contrôle sur le transfert en production, la gestion des priorités, le contenu du plan de

secours.


Le help desk informatique n’as pas été évalué ni mis en place en cas d’absence. Pour

évaluer un help desk il faut vérifier la sécurisation de la salle, la protection des données

propres au help desk, la traçabilité et archivage des actions des opérateurs, améliorer la

rapidité et la précision des prises d’appel.

5.4. Evaluation du compte rendu final

Le compte rendu final s’est fait en présence de tous les responsables des services

informatiques. C’était l’occasion de présenter aux audités les observations les plus

importantes ainsi que les conclusions dégagées issues des travaux d'audit. Cette

présentation s’est effectuée à la fin du travail de terrain et avant la rédaction du projet de

rapport.

Il s’est fait en février 2012 soit un mois après le début des travaux. Il a été question de

présenter l’ensemble des constats et de les validés avec les recommandations retenues. Ils

sont présentés individuellement en fonction de leur nature, de leur importance, et de

l’intensité de possibles dégâts. Les contestations ont étés prise en compte et classé dans le

dossier de travail.





Tous les constats ont été valides lors du compte rendu final.


Nous notons beaucoup de contestations par rapport à certains constats mais au final les

doutes sont levés, ils seront tous présent dans le rapport final.

5.5. Evaluation du rapport d’audit

Le rapport a été réalisé par le chef de mission vu son expérience afin que celui soit

conforme à la norme. Chaque constat est relu et corrigée par lui. Tous les

disfonctionnements y sont mentionnés par le chef de mission. Sur la base des constats

effectués le rapport a présenté, les différents constats organisés par thème et les

recommandations en réponse aux besoins de conformité par rapport aux normes et

référentiels utilisés. Les constats sont basés à partir des rencontres avec les responsables à

différents niveaux de la hiérarchie, des visites in situ, de l’examen de la documentation

communiquée par le service informatique.

Puis il a été question de la mise en place des recommandations, avec, notamment la

réorganisation de la fonction informatique.

5.5.1. Aspect positif de l’évaluation :

Il y’avait une synthèse de deux pages qui présentait l’objet de la mission, la durée, les

principaux dysfonctionnements et les recommandations.

Chaque constat a une cotation bien défini en fonction de la couleur affectée. Les couleurs

sont les suivantes :

o Couleur verte : bonne situation ;

o Couleur jaune : état satisfaisant ;

o Couleur orange : situation médiocre, nécessitant une attention particulière car

pouvant engendrer des dégâts ;

o Couleur rouge : situation médiocre, aucune maitrise des risques engendrés.




5.5.2. Aspect négatif de l’évaluation :

Nous ne notons aucun aspect négatif

5.6. Activités de suivi

Dans le suivi des recommandations il faut s’assurer qu’elles sont bel et bien suivies par

l’audité afin que le travail effectué par les auditeurs s’avèrent fructueux et concluant. Il

faut se tenir a la disposition de l’audité pour toutes questions d’ordre professionnelle.

Compte tenu de l’importance croissante du SI dans la réalisation des missions et dans

l’atteinte des objectifs, il nous paraissait nécessaire de lui donner une place stratégique

dans son dispositif pour :

o valider la stratégie informatique ;

o valider les choix et orientations structurantes pour le système d’information ;

o réaliser les arbitrages sur l’exécution et la planification des projets informatiques,

o ajuster les priorités et les objectifs des projets ;

o valider les budgets proposés.

La mise en œuvre du plan des recommandations par le MEF est un aspect positif des activités de suivi.

Conclusion Chapitre 5

Ce chapitre qui est plus pratique relate le déroulement de la mission d’audit, point par point

dirigée par le Cabinet Qualisys Consulting. Nous avons audités les différentes structures

organisationnelles informatiques et fournis des recommandations lors de la réunion avec

les responsables des différentes structures auditées.

Un suivi post audit s’effectue jusqu’à présent pour voir si les recommandations sont

respectées. Il en ressort d’après cet audit que la fonction SI n’as pas vraiment une place de

choix au sein de leur dispositif informationnel.

La qualité d’une mission d’audit est devenue un impératif pour tout cabinet voulant

produire un bon travail à tout commanditaire d’une mission. En toute logique il nous

conduit vers le chapitre des recommandations




CHAPITRE 6 : PRESENTATION, ANALYSE DES RESULTATS ET

RECOMMANDATIONS.

Apres notre évaluation, ce chapitre présente les résultats ainsi que nos recommandations

qui vont permettre l’amélioration de la qualité des audits du cabinet qui nous accueille.

6.1. L’analyse des résultats

Il s’agit ici de présenter les résultats issus de notre étude après nous formulerons les

recommandations.

Si a priori tous les processus dictés par l’AFAI (2012), ont été couvert, l'on a pu quand

même détecter quelques défaillances lors de la mission d’audit. Aussi bien au niveau de

l’approche par les risques qu’au niveau du respect du délai de la mission d’audit, ainsi que

la mise en place du help desk qui n’a pas été respecté. Qui à notre avis, seraient dues d'une

part au non-respect de certaines normes AFAI (2012), de la lenteur a traité certains

dossiers lors de l’audit sur site.

D'autre part, par le fait que certains auditeurs ne mettent pas à jour leurs connaissances car

le cabinet nous a communiquer aucun budget de formation pour ses cadres. Il n’y a aucune

planification qui est faite dans ce sens-là.

Ainsi, les conclusions qui découlent de cette évaluation se résument comme suit:

La première priorité caractérisée par l’approche par les risques. Aucunes études au

préalable a été effectuée la dessus alors que les normes AFAI(2012), recommandent

fortement d’effectuer une hiérarchisation des risques, suivi de son évaluation et de son

traitement avant tout audit. Cela valide l’hypothèse selon laquelle une mise à jour des

connaissances des auditeurs à travers des séminaires est indispensable.

La deuxième priorité est caractérisée par la mise en place d’un help desk informatique dans

chaque entreprise après chaque mission d’audit afin que le suivi post audit se fasse plus

efficacement.

La troisième priorité caractérisée par le respect de certaines normes de fonctionnement

comme le délai moyen de durée de l’audit qui n’a pas été respectée. D’un bimestre l’audit

s’est étendu sur 3 mois.




Les deux dernières priorités caractérisées par la mise en place d’un budget formation et un

budget de fonctionnement lors de l’audit qui ne nous a pas été communiquer. Nous

supposons qu’ils n’existent pas.

Ceci nous amène à faire les recommandations suivantes au cabinet Qualisys.

6.2. Recommandations

A l'issue des analyses effectuées, nous jugeons indispensable de faire des

recommandations aux auditeurs du cabinet Qualisys consulting en vue de l'amélioration de

la qualité des prochains audits. Ces recommandations sont les suivantes:

o mise en place d’une approche par les risques informatiques avant chaque mission,

o respecter le délai de chaque mission d’audit ;

o mise en place d’un help desk informatique dans toutes les entreprises après chaque

mission ;

o mise en place d’un budget de formation et d’un budget de réalisation de chaque

audit ;

o certifier les auditeurs au label CISA.

6.2.1. Recommandations relatives à la planification de l’audit

Nous conseillons aux auditeurs du cabinet qualisys, de constituer un référentiel de

gestion des risques informatiques avant chaque mission d’audit selon les normes AFAI

(2012), comme suit :

o identifier les événements qui peuvent avoir un impact négatif sur les objectifs ou les

opérations de l’entreprise, dont l’activité, les aspects réglementaires et légaux, la

technologie, les partenaires commerciaux, les ressources humaines et le caractère

opérationnel ;

o déterminer la nature des impacts et établir une cartographie des risques actuels et la

maintenir à jour ;

o évaluer régulièrement la probabilité et les conséquences de tous les risques

identifiés, en utilisant des méthodes qualitatives et quantitatives. La probabilité et

les conséquences associées aux risques inhérents et résiduels doivent être

déterminées individuellement, par catégorie, et par portefeuille.




6.2.2. Recommandations relatives au travail d’audit

Auditer ou mettre en place un helpdesk revient à contrôler les activités suivantes :

o la pertinence de l’organisation en place ;

o la couverture des besoins, spécialisation, centralisation ;

o La réception, enregistrement, résolution, escalade, suivi, lien avec support, clôture ;

o le suivi de l’activité ;

o le temps de réponse, délai de résolution ;

o le respect des engagements ;

o l’analyse des écarts éventuels ;

6.2.3. Recommandations relatives au fonctionnement du cabinet qualisys

Il serait souhaitable de certifier les auditeurs seniors au label CISA qui est une

reconnaissance internationale pour les compétences.

Pour les prochains exercices de fonctionnement du cabinet il faudrait élaborer un budget de

formation annuel pour former les auditeurs.

Il faudrait définir une ligne budgétaire pour chaque mission d’audit sur le terrain. Cela

augmenterait la motivation des auditeurs.

En plus de recommandations liées aux faiblesses nous recommandons il serait souhaitable

de :

o limiter la durée des audits afin d’éviter de compromettre l’indépendance des

auditeurs ;

o imposer des honoraires convenables afin d’éviter d’être sous pression quant au

résultat du rapport de l’audit et publier ces derniers afin d’imposer un climat de

transparence ;

o que les auditeurs du cabinet bénéficient des avantages concurrentiels afin de

maintenir leur intégrité intacte ;

o que le cabinet malgré ses auditeurs diplômé devrait organiser des séminaires pour

maintenir leur connaissance à jour étant leader dans la formation.




6.2.4. Mise en œuvre des recommandations

Nous avons établi un chronogramme de mise en œuvre des recommandations

Tableau 1 : Mise en œuvre des Recommandations.

Recommandations Début de la

mise œuvre Chargé de la mise en œuvre

Mettre en place une approche par les risques

selon les normes AFAI (2012), avant chaque

mission pour pallier aux menaces des risques

informatiques.

Avril 2013 Département technique

Mettre en place un help desk informatique

après chaque mission d’audit. Avril 2013 Département technique

Certifier les auditeurs au label CISA. Avril 2013 Département formation

Mettre en place chaque année un budget de

formation pour une mise à jour des

connaissances des auditeurs.

Avril 2013 Direction générale

Limiter la durée des audits comme convenu

sur la lettre de mission. Avril 2013 Département technique

Faire bénéficier aux auditeurs des avantages

concurrentiels pour garantir leur intégrité. Avril 2013 Département finance

Source : Nous-mêmes.

Conclusion

Ce chapitre nous a permis de présenter les résultats concernant la qualité d’une des

missions du cabinet Qualisys, pour en faire une analyse quant aux points de manquement

remarqués afin d’émettre des suggestions d’améliorations. Nous pensons que ces

améliorations peuvent permettre au cabinet qui nous reçoit de renforcer la qualité de ses

prochains audits pour ainsi se conformer aux normes ISACA (2012) sur l’audit

informatique.




Conclusion de la deuxième partie

Nous pouvons dire que l’évaluation de la qualité d’une mission d’audit revêt un caractère

stratégique pour un cabinet qui veut améliorer la qualité de ses futures prestations.

Cette partie nous a permis de présenter les résultats concernant la qualité d’une des

missions du cabinet Qualisys, pour en faire une analyse et émettre des recommandations.

Ces améliorations permettront au cabinet qui nous reçoit de renforcer la qualité de ses

prochains audits pour ainsi se conformer aux normes ISACA (2012) sur l’audit

informatique.

En ce qui concerne les recommandations le cabinet doit impérativement :

o Mettre en place une approche par les risques informatiques avant chaque mission,

o respecter le délai de chaque mission d’audit ;

o mise en place d’un help desk informatique dans toutes les entreprises après chaque

mission ;

o mise en place d’un budget de formation et d’un budget de réalisation de chaque

audit ;

o certifier les auditeurs au label CISA.

Ces manquements peuvent en effet, affecter la qualité des missions du cabinet et se

répercuter sur leur réputation. Ainsi, avec les recommandations faites par nos soins, nous

pensons que Qualisys Consulting deviendra à terme, le meilleur exemple en ce qui

concerne la conduite d’une mission d’audit informatique.


CONCLUSION GENERALE




La question principale à l'origine de la rédaction de ce mémoire était la suivante: comment

évaluer la qualité d’une mission d’audit informatique?

Nous y avons apporté une réponse tout au long de notre étude. Tout ceci, pour atteindre

l'objectif principal qu'on s'était fixé, qui était d'apprécier la différence entre la qualité

détenue et la qualité voulue après chaque mission.

Premièrement nous avons parlé de la conduite de la mission d’audit, de la mise en place de

la méthodologie d’audit ensuite dans une seconde partie traité de l’évaluation de notre

mission puis nous l’avons analyser et formuler des recommandations.

A cet effet, un des outils performants utilisés de nos jours est l'évaluation permanente de la

qualité après chaque mission pour en déceler les dysfonctionnements pour les améliorer

par la suite en proposant des solutions adéquates à chaque problème. De notre avis, nous

pensons pour l'ensemble atteint cet objectif.

Cette étude nous a permis à travers notre démarche référentielle, de faire l'évaluation de la

qualité de notre mission d’audit. Notre démarche nous a ainsi servi pour atteindre les

objectifs spécifiques que nous nous sommes fixés en début de ce mémoire. En outre, cette

étude nous a permis:

o de mettre en place un référentiel d’audit,

o de mettre en place notre méthodologie d’évaluation de la qualité d’une mission

d’audit informatique,

o d’identifier les indicateurs de la qualité d’une mission d’audit et de les évaluer de

façon approximative.

Par cette évaluation, nous avons pu faire les analyses et les recommandations.

Même si l'application de ces recommandations de façon globale et systématique reste a

priori incertaine, mais l’idéal serait si le cabinet applique nos recommandations afin

d’améliorer la qualité des prochains audits car d’après Villalonga (2006 : 20), dans son

ouvrage manager avec efficacité le processus qualité, il dit que l'impact de la qualité touche

toutes les procédures de travail au sein des cabinets désormais.


ANNEXES




Annexe 1 : Organigramme du Cabinet

Source : Cabinet Qualisys.




Annexe 2 : Cartographie des Risques

Activités / Processus informatiques

Echelle de cotation : 1 à 10

Probabilité de survenance : 1% a 10%

Activité Opérations Systeme information

Informatique

Juridique

Image administratif

Formation des utilisateurs

Elaboration de programmes et supports Organisation de formation Délivrance de formation Elaboration de guide utilisateur

4 4

4 4 4

Perfectionnement Informaticien

Formation Veille technologique

4

4

4 4

Maintenance applicative

Qualification des anomalies Modification de programmes ou paramètres Mise à jour de documentation Adaptation par rajout de modules Tests des modifications Tests de non régression Suivi des contrats de maintenance Suivi de traitement d'anomalie indicateurs (incidents/interventions)

6 4 4 6 4

9 4 6 6 6

6

6 9 4 6 4

Gestion du programme informatique

Elaboration du Plan stratégique Conception de programme annuel d’activités Suivi de l'exécution de programme Suivi des prestataires externes Bilan du programme annuel d’activités Elaboration des plans d’action Elaboration du budget informatique Evaluation du personnel informatique

4 4

4

4 4 4 4 4 4 4 4 4

Administration du serveur de messagerie

Planification des système Domino Configuration, maj du serveur messagerie Gestion de la messagerie Gestion du serveur Domino Gestion des utilisateurs Gestion des bases Notes Sécurisation du serveur Domino Gestion des licences

4 6 6 6 6 6 9 6

4 6 6 6 9 9 9 6

6

6

4 6

Administration des systèmes

Installation et configuration des systèmes

6 6

6 6





Informatique

Juridique

Image administratif

Installation et configuration de base de données Analyse et optimisation des performances des systèmes Analyse et optimisation des performances de base de données Maintenance des systèmes Maintenance de base de données Surveillance des systèmes Surveillance de bases de données Gestion du parc de systèmes Installation et configuration de poste de travail Installation et configuration des périphériques utilisateurs Gestion des licences

6 6 6 6 6 6 4 6 6 6

6 6 6 6 4 4 4 6

6

6

4 4 4 6

Sauvegarde / Restauration

Programmes sources Données Utilisateurs Applications Logiciels Base de données Versions applications Versions logiciels Serveurs Sécurité système Documentation Site Web Configuration Réseau Firewall Gestion des supports magnétiques Définition des normes et procédures

6 9 9 9 9 6 6 9 9 6 6 9 9 6

6 9 9 9 9 6 6 9 9 6 6 9 9

6 6

6

6 9 9 9 9 6 6 9 9 6 6 9 9 9 6

Gestion de la Sécurité

Définition des stratégies de sécurité Mise en place des stratégies de sécurité Installation et mise à jour des antivirus Gestion des virus Gestion des habilitations (comptes Agents) Gestion des habilitations (comptes stagiaires) Gestion des mots de passe Gestion des accès aux locaux informatiques Gestion des indicateurs d’incidents Gestion des licences

9 9 9 9 9 9 9 9 5 7 7

9 9 9 9 9 9 9 9 6 6 6

6 6

6 6

6 6 6 6





Informatique

Juridique

Image administratif

Définition des normes et procédures

Maintenance matérielle

Diagnostic des pannes Réparation des pannes Maintenance préventive Suivi des prestataires extérieurs Gestion des indicateurs de pannes Gestion des pièces détachées Définition des normes et procédures Gestion des garanties

4 6 6

4 4 6 4

6

6 4 4 6 4

Production

Planification de l'exploitation Exploitation des applications Certification des factures travaux informatiques Facturation des impressions Allocation de ressources (séminaires, étudiants, Agents) Gestion des indicateurs de production Définition des normes et procédures

6 6 4 4 4 4 6

4 4 6 4 6 9

4 4 6 9

Mise en œuvre des progiciels

Paramétrage Déploiement des logiciels Adaptation par rajout de modules Formation des utilisateurs Assistance aux utilisateurs Définition des normes et procédures Gestion des licences

6 4 4 6 4

6 6 6 6

4

4 4 4 6 4

Maintenance des progiciels

Adaptation par rajout de modules Test des modifications Mise à jour de la version en production Mise à jour de la documentation Formation des utilisateurs Définition des normes et procédures Gestion des licences

6 6 9 4 4 6 4

6 6 9 4 6 4

4

4 4 6 4

Administration des réseaux

Elaboration du schéma de réseau Analyse et optimisation des performances Supervision du réseau Maintenance du réseau Définition et mise en place des règles sur le firewall Administration du firewall Gestion du parc d'éléments actifs(routeurs) Installation et configuration des équipements

6 6 6 6 9 9 4 4 6

6 4 4 6 9 9 9 9 9 9

4 6





Informatique

Juridique

Image administratif

Installation et configuration des accès Internet contrôle disponibilité de la ligne Internet Installation et configuration des commutateurs Brassage et mise en réseau des équipements Gestion de la relation avec les fournisseurs Gestion des indicateurs réseaux Définition des normes et procédures

6

9 6

6

4

4 6

Administration du site Web

Conception du site Web Pilotage du Site Web Mise a jour du Site Web Gestion des indicateurs Définition des normes et procédures

6 6 6 4 4

6 6 6 6

6 6 6

6 6 6 4 4

Assistance aux utilisateurs

Recueil des demandes d’assistance Traitement des demandes d’assistance Suivi des demandes d’assistance Gestion des indicateurs d’assistance Définition des normes et procédures

4 4 4 4 6

4 4 4 4

4 4 4 4 6

Gestion du parc informatique

Réception d’équipement informatique Gestion des prêts d’équipement informatique Affectation et livraison d’équipement informatique Mise au rebut du matériel retiré d’inventaire Retrait d’équipement du parc informatique Suivi du parc informatique (entrée / sortie) Définition des normes et procédures Gestion de la garantie Gestion des indicateurs de mouvements

4

4

4 4 4 4 4 4 6 4 4




10 Crise majeure9 Extrêmement grave8 Fortement grave7 Très grave6 Grave5 Moyennement grave4 Peu grave3 Très peu grave2 Extrêmement peu grave1 Inoffensif

Gravité moyenne des conséquences

Annexe 3 : Exemple d’échelle d’évaluation des risques informatiques

Source : COSO.

Source : COSO

10 Quasiment certain / Avéré9 Extrêmement probable8 Fortement probable7 Très probable6 Probable5 Moyennement probable4 Peu probable3 Très peu probable2 Extrêmement peu probable1 Quasiment impossible

Probabilité d'occurrence moyenne




Annexe 4 : Plan de travail d’audit

PROJET Audit PLAN D’AUDIT Date : Version : 1.0

Période de l'audit : Domaine de l’audit : AUDIT ORGANISATIONNEL (Organisation de la sécurité de l’information, Management de la sécurité de l’information, Gestion des Processus)

Structure :

Adresse :

Equipe d’audit : Equipe

DI :

Types d’actifs audités :

TYPE ORG – ORGANISATIONS

« mettre la définition ici »

TYPE PERS – PERSONNES


TYPE PROC – PROCESSUS


Champ d’audit Activité à auditer / objectif de sécurité à identifier

Listes des actifs

Personne / à rencontrer au sein de la structure et ses coordonnées

Date /Heure Prévue

Auditeurs

Audit

Organisation

de la sécurité

de

l’information

01A - Rôles et structures de la

sécurité

01B - Référentiel de sécurité

01C - Gestion des ressources

humaines

01D - Assurances

Audit

Management

de la sécurité

de

l’information

14A - Planification du système

de management

14B - Déploiement du système

de management

14C - Mise sous Contrôle du

système de management

14D - Amélioration du système

de management

14E – Documentation

14F - Maturité de la SSI




Audit Gestion

des Processus

13A - Protection des

renseignements personnels

13B - Communication

financière

13C – Protection des processus

métiers

13D - Protection de la propriété

intellectuelle

13E - Protection des systèmes

informatisés

13F - Sécurité des personnes et

protection de l'environnement

13G - Règles relatives à

l'utilisation de moyens

cryptologiques

13H - Cadre réglementaire

applicable au Sénégal (CRS)

Note :

Source : Documentation cabinet qualisys consulting.


BIBLIOGRAPHIE




Ouvrages

1. ANGOT Hugues (2004), Audit comptable et audit informatique, 3eme Edition,

Editions de Boeck université, Paris, 300 Pages ;

2. BATSCH Laurent (2008), Finance et Société, 1ere Edition, Edition Economica,

Paris, 392 Pages ;

3. BITTERLI Petter (2008), Guide d’audit des applications informatiques, Edition

AFAI, Paris, 50 Pages ;

4. COLUMBA Sara Evelyn (2012), Audit informatique, Edition Fec publishing, Paris,

180 Pages ;

5. CRUCHANT Laurent (1998), Que sais-je de la qualité ?, 4e édition, Presses

Universitaires de France, Paris, 100 pages ;

6. DERRIEN Yann (1992), Les techniques de l’audit informatique, 1ere Edition,

Edition Dunod, Paris, 240 Pages ;

7. FUSARO Peter, MILLER Ross (2003), Enron, les vraies raisons de la chute,

Edition SB.COM, Paris, 196 Pages ;

8. GOGUE (1997), Management de la qualité, 2e édition, Edition Economica, Paris,

100 Pages ;

9. GOGUE (2000), Traité de la qualité, 2e édition, Edition Economica, Paris, 180

Pages ;

10. Le Petit Larousse illustré (2001), Les Editions Françaises Inc., 1784 Pages ;

11. LERAY Jean (2010), Gérer les risques, Edition Afnor, Paris, 392 Pages ;

12. MOISAND Dominique, GARNIER de Labareyre, Fabrice (2009) CobiT : Pour une

meilleure gouvernance des systèmes d’information, Edition Eyrolles, Paris, 120

Pages ;

13. REIX Robert, ROWE (2011), Systèmes d’Information & Management des

Organisations, Éditions Vuibert, Paris, 180 Pages ;

14. THORIN Marc, (1997), L’Audit informatique, méthodes règles et normes, 3eme

Edition, Edition Hermes, Paris, 174 Pages ;

15. VILLALONGA Christophe, (2006), l’audit qualité interne, manager avec efficacité

son processus qualité, 2e édition, Edition dunod, Paris, 150 Pages ;




Articles consultés

16. BOMBAL Sébastien (2006), Pourquoi commanditer un audit ?, la revue n°82

ALTIOR, 11 Pages ;

17. BLE KOFFI Charles (2013), l’audit des systèmes d’informations, syllabus cours

master cesag ;

18. COHEN Didier (2006), les outils de l’audit informatique, séminaire de lancement

du projet d’observatoire AFAI ;

19. DeAngelo (1981), Auditor Size and Audit Quality, Journal of Accounting and

Economics, (200):183-199;

20. DETHIER Jean louis (2007), Les enjeux des indicateurs, société française

d’évaluation, (21 P) : 1-10 ;

21. FUERMAN (2004), Audit quality examined one large CPA firm at a time: MID-

1990’s empirical evidence of a precursor of Arthur Anderson’s collapse, Corporate

Ownership and Control, volume 2, 148 pages;

22. HARBOUR Jerry, (1997), Performance measurement, Corporate Ownership and

Control, 71 pages;

23. LAFORCADE Michel (2004), Evaluation et la démarche qualité face au défi de la

complexité, fichiers/texte Législatif/art_laforcade_loi_renov.pdf, 82 Pages.

24. MANITA (2005), Comité d’audit et qualité de l’audit externe : vers le

développement d’un outil d’évaluation de la qualité du processus d’audit, Thèse de

doctorat non publiée, Besançon : Université de Franche-Comté, (100) :1-10 ;

25. PIGE (2004), Audit quality examined one large CPA firm at a time: MID-1990’s

empirical evidence of a precursor of Arthur Anderson’s collapse, Corporate

Ownership and Control, vol. 2, 100 pages;

26. PRAT dit Hauret (2000), L’indépendance du commissaire aux comptes : cadre

conceptuel et analyse empirique, Thèse de doctorat non publiée, Bordeaux :

Université de Montesquieu-Bordeaux IV. 200 pages ;

27. WOOTEN (2003), Research about Audit Quality, CPA Journal;

28. YAZI Moussa (2009), Méthodologie de rédaction du mémoire, Masters et DESS

cesag ;




Sites Internet consultés

29. ISACA (2008), La sécurité informatique les référentiels et l’auditeur,

http://www.afai.fr/index.php?m=89;

30. ISACA (2004), Norme d’audit des systèmes d’informations, éthique et normes

professionnelles, http://www.isaca.org/Knowledge

Center/Standards/Documents/Standards-IT-French-S3.pdf;

31. ISCA (2008), Les normes d’audit des systèmes d’informations,

http://www.isaca.org/knowledge-center/standards/documents/standards-it-french-

s14.pdf, septembre 2012 ;

32. ISO (2012), Le management de la qualité ISO 9000,

http://www.iso.org/iso/fr/home/standards/management-standards/iso_9000.htm,

septembre 2012 ;

33. ISA (2004), Résumé des normes internationales d’audit, document interne FIDEF,

http://www.aud-it.ch/normes.html;

34. IFACI (2005), Le management des risques de l'entreprise,

http://www.numilog.com/package/extraits_pdf/e235340.pdf;

35. Le journal du net (2010), http://www.journaldunet.com/solutions/0602/060224-

analyse-audit-10-conseils.shtml ;

36. WIKIPEDIA (2010), Définition de l’audit informatique,

http://fr.wikipedia.org/wiki/Audit_informatique.


http://www.afai.fr/index.php?m=89

http://www.isaca.org/Knowledge%20Center/Standards/Documents/Standards-IT-French-S3.pdf

http://www.isaca.org/Knowledge%20Center/Standards/Documents/Standards-IT-French-S3.pdf

http://www.isaca.org/knowledge-center/standards/documents/standards-it-french-s14.pdf

http://www.isaca.org/knowledge-center/standards/documents/standards-it-french-s14.pdf

http://www.iso.org/iso/fr/home/standards/management-standards/iso_9000.htm

http://www.aud-it.ch/normes.html

http://www.journaldunet.com/solutions/0602/060224-analyse-audit-10-conseils.shtml

http://www.journaldunet.com/solutions/0602/060224-analyse-audit-10-conseils.shtml