CDR Outil Informatique

Cahier de la
Recherche
Slectionner un outil informatique

pour les services daudit et
de contrle internes :
un vritable projet
Ralis par lUnit de Recherche Informatique
LIFACI est affili

The Institute of Internal Auditors
SLECT IONNER UN OUT IL IN FOR MATI QU E POUR L ES SERV I CES D AUDI T ET DE CONT R L E I NT ERN ES : U N V RI TA B LE PROJET
DANS
LA MME COLLECTION
Laccs et la conservation des documents relatifs aux missions daudit, Unit de Recherche IFACI
(novembre 2012)
La dlgation de gestion en assurance de personnes : pistes pour un contrle interne efficace, Unit
de Recherche IFACI (juin 2012)
Les variables culturelles du contrle interne, Unit de Recherche IFACI (dcembre 2011)
Des cls pour la mise en uvre et loptimisation du contrle interne, Unit de Recherche IFACI (octobre 2011)
Transposition des normes professionnelles de laudit interne et bonnes pratiques : Edition spciale
Administrations dEtat, Groupe Professionnel Administrations de lEtat (septembre 2011)
Transposition des normes professionnelles de laudit interne et bonnes pratiques : Edition spciale
Collectivits Territoriales, Groupe Professionnel Collectivits territoriales (avril 2011)
La fraude : Comment mettre en place un dispositif de lutte contre la fraude ? Unit de Recherche de
lIFACI (dcembre 2010)
La cration de valeur par le contrle interne, Unit de Recherche de lIFACI (octobre 2010)
Prise de Position du Groupe Professionnel Banque pour un urbanisme du contrle interne efficient, Groupe Professionnel Banque (Avril 2010)
Laudit de la fraude dans le secteur bancaire et financier, Unit de Recherche de lIFACI (janvier 2010)
Cration et gestion dune petite structure daudit interne, Unit de Recherche IFACI (janvier 2009)
Une dmarche daudit de plan de continuit dactivit, Unit de Recherche IFACI (juillet 2008)
Guide daudit du dveloppement durable : comment auditer la stratgie et les pratiques de dveloppement durable ?, Unit de Recherche IFACI (juin 2008)
Contrle interne et qualit : pour un management intgr de la performance, Unit de Recherche
IFACI (mai 2008)
Evaluer et dvelopper les comptences des collaborateurs, Antenne rgionale Aquitaine IFACI (novembre 2007)
Audit des prestations essentielles externalises par les tablissements de crdit et les entreprises
dinvestissement 2me Edition, Groupe Professionnel Banque (janvier 2007)
La cartographie des risques, Groupe Professionnel Assurance (juillet 2006)
Laudit interne et le management des collectivits territoriales, Unit de Recherche IFACI (mai 2006)
Une dmarche de management des connaissances dans une direction daudit interne, Unit de
Recherche IFACI (mai 2006)
Lauto-valuation du contrle interne, Unit de Recherche IFACI (octobre 2005)
Cartographie des Risques, Groupe Professionnel Immobilier Locatif (septembre 2005)
tude du processus de management et de cartographie des risques, Groupe Professionnel Industrie
et commerce (janvier 2004)
Pour un bon audit du dispositif de lutte contre le blanchiment des capitaux, Groupe Professionnel
Banque (fvrier 2004)
Lefficacit des Comits daudit Les meilleures pratiques, PwC The IIA Research Foundation
Traduction IFACI PwC (mai 2002)
Gouvernement dentreprise et Conseil dadministration, PwC The IIA Research Foundation
Traduction IFACI PwC (mai 2002)
valuation de la comptence dans la pratique de laudit interne, Prise de position de lECIIA
Traduction IFACI (2001)
Management des risques, IIA UK Traduction Unit de Recherche IFACI (2001)
Le rle de lauditeur interne dans la prvention de la fraude, Prise de position de lECIIA Traduction
IFACI (2000)
Pour plus dinformations : www.ifaci.com
IFACI Paris janvier 2013
ISBN : 978-2-915042-46-7 ISSN : 1778-7327
Toute reprsentation ou reproduction, intgrale ou partielle, faite sans le consentement de lauteur, ou de ses ayants droits,
ou ayants cause, est illicite (loi du 11 mars 1957, alina 1er de larticle 40). Cette reprsentation ou reproduction, par
quelque procd que ce soit, constituerait une contrefaon sanctionne par les articles 425 et suivants du Code Pnal.
IFACI
R EMERCIEMENTS
LIFACI tient tout particulirement remercier les membres de lUnit de Recherche Informatique
(URI) qui ont particip llaboration de ce Cahier :
Jos Bouaniche, Auditeur, CAISSE DES DPTS ET CONSIGNATION, Prsident de lURI ;
Eric Richard, Auditeur informatique, CRDIT LOGEMENT, membre de lURI ;
Olivier Sznitkies, Audit Director, LAFARGE GROUP AUDIT, membre de lURI ;
Yohann Vermeren, Director, KPMG ADVISORY, membre de lURI.
LIFACI remercie galement pour leur participation la relecture :

Laurent Arnaudo, Directeur de l'Audit Interne - Senior Vice President, SODEXO, Prsident du Groupe
professionnel Contrle interne ;
Frdric Barge, Auditeur, BANQUE DE FRANCE ;
Jean-Pierre Bouillot, VP Information System Audit, Risk Committee Project Leader, SANOFI, membre
de lURI ;
Sbastien Darrieux, Inspecteur, BANQUE DE FRANCE ;
Marie-Christine Garcia, Directeur de l'audit informatique, RENAULT, membre de lURI ;
Philippe Hervias, Director IS Security & Infrastructure Audit, SANOFI, membre de lURI ;
Alain Rogulski, IS/IT Audit Director, SODEXO, membre de lURI ;
Marie-Christine Rozier, Auditeur informatique, BANQUE DE FRANCE ;
Jrme Semik, Responsable du Contrle interne, LAGARDERE, membre du Groupe professionnel
Contrle interne.
La rvision a t assure par :

Perrine Bnard, Documentaliste, IFACI ;
Batrice Ki-Zerbo, Directeur de la Recherche, IFACI.
Philippe MOCQUARD, Dlgu Gnral, IFACI
IFACI
S OMMAIRE
1.
Prambule ......................................................................................................................................................... 5
1.1 Une dmarche prenant en compte les risques ........................................................................................ 8
1.2 Les rles dans la gestion de projet ........................................................................................................... 8
1.3 Faut-il avoir recours un prestataire externe ? Ce que lon doit en attendre .................................... 10
1.3.1 Lassistance lexpression du besoin ainsi qu la slection du logiciel .................................... 10
1.3.2 Le dploiement et ladaptation dun progiciel ............................................................................. 11
2.
Une dmarche structure ............................................................................................................................ 12

2.1 Dfinir les activits, les objectifs et les priorits .................................................................................... 14
2.2 Apprcier les risques la mesure des bnfices attendus .................................................................... 16
3.
Exprimer les besoins .................................................................................................................................... 18

3.1 Partir des besoins pour orienter les choix .............................................................................................. 19
3.2 Les besoins les plus couramment informatiss : exemple dun service daudit interne .................... 22
3.2.1 Pilotage du service .......................................................................................................................... 23
3.2.2 Conduite de mission ...................................................................................................................... 24
3.2.3 Travail terrain .................................................................................................................................. 24
3.3 Formaliser la phase dexpression des besoins ....................................................................................... 25
4.
La dmarche de slection ............................................................................................................................ 27

4.1 Etudier les options ................................................................................................................................... 29
4.1.1 De nombreuses options possibles ................................................................................................ 29
4.1.2 Les solutions logicielles les plus couramment utilises .............................................................. 31
4.2 Etudier loffre commerciale ..................................................................................................................... 35
4.3 Evaluer les progiciels et slectionner un outil ....................................................................................... 39
5.
Maquetter / dvelopper / paramtrer ...................................................................................................... 42
6.
Stratgies de tests, de dploiement et de gestion du changement. Pourquoi, jusquo ? ............. 43

6.1 Dvelopper les stratgies de tests et de dploiement ........................................................................... 44
6.2 Grer le changement ............................................................................................................................... 46
7.
Maintenance / administration .................................................................................................................... 47
8.
Le dur exercice du miroir : savoir faire un bilan .................................................................................... 50
9.
Annexes ........................................................................................................................................................... 52
Annexe 1 - Conseils si lon ralise soi-mme loutil .................................................................................. 53
Annexe 2 - Organisation de sessions participatives d'expression des besoins ........................................ 54
Annexe 3 - Etat des lieux des besoins .......................................................................................................... 56
Annexe 4 - Exemples de grille de slection ................................................................................................. 61
Exemple 1 .................................................................................................................................................. 61
Exemple 2 .................................................................................................................................................. 62
Exemple 3 .................................................................................................................................................. 66
Exemple 4 .................................................................................................................................................. 67
Annexe 5 - Lanalyse des donnes ............................................................................................................... 68
Annexe 6 - Outils daudit et de contrle en continu .................................................................................. 69
Annexe 7 - La fiabilit des donnes ............................................................................................................. 71
Annexe 8 - Tableau rcapitulatif des risques pouvant entraner lchec du projet / Rponses ............... 73
10. Bibliographie .................................................................................................................................................. 76

IFACI
PARTIE 1
P RAMBULE
IFACI
Les services daudit ou de contrle internes se trouvent inluctablement confronts la ncessit

de mettre en uvre des logiciels, que ce soit pour piloter leurs activits ou pour les exercer.
De la ncessit de recourir des solutions informatiques

Les rsultats de lenqute internationale CBOK 20101 illustrent la ncessit, dans des environnements de plus en plus complexes, de recourir des solutions informatiques.
2010
2015
France Europe Monde France Europe Monde

Extraction de donnes
68%
47%
51%
53%
52%
63%
Documents de travail lectroniques
57%
54%
62%
53%
55%
50%
Techniques daudit assistes par

ordinateur
21%
47%
53%
60%
63%
65%
Logiciel de flowchart
39%
36%
50%
40%
35%
25%
Application de cartographie des

processus
36%
28%
24%
57%
37%
52%
Selon cette enqute, les principales finalits des outils informatiques en France sont :
lextraction de donnes (pour 68% des rpondants en France ce qui est largement suprieur
aux 47% constats en Europe et 51% dans le monde) ;
la gestion de documents de travail lectroniques (57%) ;
les logiciels de flowchart (39%) ou de cartographie des processus (36%).
Si en 2010 lutilisation de techniques daudit assistes par ordinateur ntait pas trs rpandue en
France (21% contre 53% au niveau mondial), elle devrait fortement progresser puisque 60% des
rpondants font part de leur volont de se doter de ce type de technologie lhorizon 2015.
Lutilisation dapplication de cartographie des processus devrait galement progresser de 36%
57%.
Le recours accru aux technologies de linformation est une tendance gnrale dans chaque mtier.
Les auditeurs et les contrleurs internes ne sont pas en marge de cette dynamique, ils comptent
tirer parti des opportunits offertes par ces outils pour amliorer leur efficacit.
Imperatives for Change: The IIAs Global Internal Audit Survey in Action (The IIAs Global Internal Audit Survey: A Component of the
CBOK Study) / Richard J. Anderson, J. Christopher Svare. IIA, 2011.
IFACI
Les avantages les plus couramment attendus dune solution informatique, support dun service
daudit ou de contrle internes sont :
Amliorer la productivit en facilitant le travail des auditeurs et des contrleurs internes ;
Capitaliser le savoir ;
Homogniser les pratiques ;
Faciliter et tracer la supervision ;
Avoir une vision synthtique sur les risques et les plans dactions ;
Faciliter la planification des missions daudit et des activits de contrle ;
Faciliter la ralisation des missions d'audit et acclrer lmission des rapports ;
Amliorer le suivi des recommandations ;
Adopter les meilleures pratiques professionnelles et pouvoir rendre compte de leur mise en
uvre travers le suivi dindicateurs de pilotage.
Pour slectionner leurs outils, les services daudit ou de contrle internes devront mettre en uvre
une gestion de projet structure, pour garantir la satisfaction de leurs besoins face une offre
plthorique teinte dun jargon technique (cf. 4.2 Etudier loffre commerciale , p. 35).
La mise en place doutils informatiques dans un service ne relve ni de lvidence, ni de linstantan
et sa russite ne doit rien au hasard. Quil sagisse de tirer parti des outils bureautiques classiques
(Word, Excel) ou de mettre en place des outils de gestion de bout en bout , il est important de
garder lesprit que la technologie doit rester au service de lefficacit et du professionnalisme.
La dmarche prsente dans ce guide pratique est centre sur lacquisition et la mise en uvre dun
progiciel. Elle sera utile pour des personnes qui ne sont des professionnels ni de linformatique, ni
de la gestion de projet.
Devant la diversit des problmatiques, il nest pas envisageable de proposer une dmarche monolithique. Cest pourquoi, nous vous engageons ne retenir que ce qui vous permet de faire face
vos risques.
IFACI
1.1
U NE DMARCHE
PRENANT EN COMPTE LES RISQUES
Dans la ralit dun projet, il est malheureusement bien souvent impossible didentifier ds labord
les lments de risque. Un projet que lon penserait simple, ne ncessitant que la mise en uvre
dun tableur par exemple, peut tre porteur de difficults insouponnes ayant pour origine des
concepts ou des notions non partages par les acteurs du projet, des prsupposs parcellaires, des
impacts organisationnels complexes, etc.
Cest pourquoi, tout au long dun projet, ft-il a priori le plus simple, il faudra organiser des points
davancement rguliers avec un suivi des risques rigoureux. Il faut souligner que les risques ne sont
pas uniquement dordre financier (cf. annexe 8 Tableau rcapitulatif des risques pouvant entraner
lchec du projet / Rponses , p. 73). En effet, dautres lments dordre organisationnel, fonctionnel, technique ou humain peuvent gnrer des risques qui seront traiter.
Risque
Echec du projet (sur les dlais, le budget et la
satisfaction des besoins).
1.2 L ES
Rponses
Suivre une dmarche partage.
Raliser un planning raliste.
Raliser des points davancement rguliers
avec des jalons prdfinis (cf. 2.2 Apprcier
les risques la mesure de bnfices attendus ,
lencart sur la notion de jalon , p. 16).
RLES DANS LA GESTION DE PROJET
Comme dans tout projet, les rles et responsabilits doivent tre clairement dfinis avant le lancement du projet (cf. annexe 1 Conseils si lon ralise soi-mme loutil , p. 53). Un document doit
formaliser les affectations de chaque personne implique, la charge estime de travail sur le projet,
la frquence des runions de travail et davancement, ainsi que les contributions attendues.
La structure de projet type prsente, ci-aprs, est ajuster en fonction de lampleur de votre
quipe.
Le sponsor du projet a la responsabilit darbitrer les dcisions cls (il pourra sagir du
responsable de laudit interne ou du responsable du contrle interne).
Le comit de pilotage (il peut tre compos du sponsor, du RAI ou du RCI, du chef de
projet, du DSI, etc.) :
- valide la stratgie et les modalits de mise en uvre ;
- dfinit les orientations ;
- valide les priorits et les objectifs ;
- traite les points bloquants, prend les dcisions et assure la rsolution des problmes
critiques (ressources et financement).
IFACI
Le comit de projet (il se compose du chef de projet, des reprsentants des utilisateurs, des
prestataires informatique internes ou externes) :
- formalise lexpression des besoins ;
- suit lavance de lensemble des travaux ;
- alerte sur les ventuelles difficults rencontres et les dysfonctionnements constats ;
- analyse les points de dysfonctionnement et dfinit les actions correctives associes ;
- met en uvre les dcisions du comit de pilotage.
Bien videmment, pour un logiciel impliquant un projet relativement limit, cette organisation
pourra tre largement simplifie tout en gardant lesprit limportance de limplication des futurs
utilisateurs.
Sassurer que lensemble des services impacts par le dploiement de loutil informatique soit
partie prenante du comit de pilotage.
Inclure les bons acteurs. Pour ce faire, il faudra notamment :
tre attentif au profil du chef de projet, par exemple le responsable qualit et mthodes du
service daudit ou tout autre auditeur interne ayant une vision claire des besoins et une aptitude grer le projet ;
considrer, toutes les tapes du projet, le point de vue de ceux qui vont utiliser loutil au
quotidien (auditeurs internes, contrleurs internes voire responsables de processus pour le
suivi des recommandations ou les outils de contrle interne) ;
veiller la reprsentativit des utilisateurs (seniors / juniors, expertise, localisation gographique, etc.). Il faudra aussi faire attention la disponibilit des utilisateurs dans le cadre du
projet (les utilisateurs les plus pertinents sont souvent les moins disponibles).
Associer le prestataire informatique interne en amont du projet pour apprcier la capacit dintgration du SI de lorganisation et la capacit dlivrer les performances attendues, mme lors
dune acquisition dun progiciel du march.
IFACI
1.3 FAU T- I L
AVO IR RECO URS UN PRE STATAI RE EXTE RNE
? CE
Q UE L O N DO IT EN
ATTENDRE
Choisir de se faire assister par des prestataires peut permettre de gagner du temps, de bnficier de
mthodologies de gestion de projets et dune connaissance approfondie du march. Il convient
nanmoins de slectionner avec prcaution ses conseils.
Risque
Rponses
Mconnaissance de lorganisation.
valuer les connaissances sectorielles du

prestataire. Le donneur dordre doit sassurer
que le prestataire dispose dune bonne
connaissance des exigences sectorielles, de
lorganisation et des organisations similaires.
Mconnaissance des besoins.
Expliciter les objectifs et les rsultats attendus.

Le donneur dordre doit tre clair sur ses
objectifs et les rsultats quil attend de la
mission confie au prestataire.
valuer la bonne comprhension, par le
prestataire, des besoins, des enjeux et des
spcificits du mtier dauditeur interne et/ou
de contrleur interne.
Manque dindpendance du prestataire.
valuer les liens conomiques du prestataire

vis--vis des diffrents diteurs du march.
Identifier dautres critres permettant de
supporter limpartialit du prestataire.
Deux tapes peuvent tre judicieusement ralises avec laide dun prestataire :
lassistance lexpression du besoin, ainsi qu la slection du logiciel ;
ladaptation et le dploiement de loutil.
Le prestataire est invit certaines runions du comit de projet introduit au I. 2, p. 8. Il change
rgulirement avec le chef de projet qui est gnralement un collaborateur dun des services utilisateurs.
1.3.1 Lassistance lexpression du besoin ainsi qu la slection du logiciel

Un prestataire pourra aider le service laborer un cahier des charges et organiser la slection du
fournisseur.
IFACI
10
Les attentes vis--vis dune quipe de consultants seront alors :

une vritable orientation mtier. Avec une prise en compte des problmatiques audit et
contrles internes, le prestataire devra connatre et comprendre les processus et fonctionnement des services daudit interne ou contrle interne mais aussi du secteur dactivit de
lorganisation. Cela permettra de dfinir de manire efficace les besoins pertinents ;
lindpendance. Le prestataire ne doit pas avoir dattache conomique avec un fournisseur
pour :
- assister avec objectivit / prise de recul lorganisation lors de lanalyse des fonctionnalits de chaque solution ;
- pouvoir valuer les problmatiques techniques.
1.3.2 Ladaptation et le dploiement dun progiciel

Dans ce cas, le donneur dordre fera appel un intgrateur ou un diteur qui proposera de raliser
avec ses propres quipes les dveloppements spcifiques et les personnalisations. Trs souvent,
dans le cadre du march des logiciels de support laudit interne et au contrle interne, ladaptation ne pourra se faire que par lditeur.
Dans les cas o le paramtrage de loutil noffrirait pas de solution approprie aux besoins exprims, lintgrateur peut proposer la ralisation de dveloppements spcifiques (cf. 5 Maquetter /
dvelopper / paramtrer , p. 42).
Nanmoins, dans les deux cas, comme pour tout recours un prestataire, il est fondamental pour
chaque organisation de conserver, dune part, la matrise du projet et des dcisions, et dautre part,
le savoir li loutil et son fonctionnement.
Risque
Rponses
Manque de connaissances de loutil.
valuer lexprience de lintgrateur au regard

de la solution choisie.
Obtenir auprs de lditeur et/ou de
lintgrateur une liste de rfrences.
Sassurer que la prestation de service ne soit
pas ralise uniquement par des juniors , et
quelle comporte un niveau suffisant
dimplication des experts ou managers.
Sur-adaptation du progiciel.
Privilgier au maximum le paramtrage au

dveloppement spcifique, afin de permettre
une monte de version aise.
Ne jamais toucher au noyau du progiciel
(ligne rouge ne pas franchir et dterminer
avec l'diteur) au risque dentraner le
dsengagement de l'diteur.
IFACI
11
PARTIE 2
U NE
IFACI
DMARCHE STRUCTURE
12
La dmarche que nous proposons est illustre par le schma ci-dessous.
Stratgie dentreprise
Contraintes juridiques
et rglementaires
Exigences normatives
et professionnelles
Exigences oprationnelles
Tenir compte de lenvironnement
Exprimer le besoin
et formaliser le
business case
BESOINS
& OPTIONS
NO GO
Concevoir les tests

et la stratgie de test
Etudier les options
Evaluer les logiciels

NO GO
Choisir le logiciel
Analyser
et grer
les risques
CHOISIR
Maquetter
Dvelopper
Tester
GRER
Mettre en place
Administrer
et maintenir
Dmarche de mise en place dun outil
IFACI
13
Mettre en place un outil passe par les tapes suivantes :

tenir compte de l'environnement ;
exprimer les besoins et les prioriser selon quils soient essentiels, de confort, etc. ;
tudier les options (acquisition dun logiciel, dveloppement, rorganisation, volution,
partage, ne rien faire, etc.) ;
concevoir une stratgie de test cohrente avec les besoins ;
valuer les logiciels et les faire fonctionner (proof of concept) ;
choisir le logiciel dployer ;
maquetter, dvelopper, paramtrer ;
tester ;
mettre en place (reprise de lexistant, formation des utilisateurs, etc.) ;
administrer et maintenir.
Loin dtre une marche force pour lacquisition dun outil tout prix, cette dmarche permet de
se poser la question de lopportunit et de la pertinence du projet ds le dmarrage et aux tapes
cls. Elle pourra donc aboutir larrt ou la suspension du projet jusqu ce que les conditions de
succs soient runies.
Les tapes dtailles ci-aprs seront plus ou moins suivies, plus ou moins approfondies, selon vos
risques, vos contraintes et vos besoins.
C'est chacun, utilisant le bon bout de sa raison , de dcider en conscience de la marche suivre,
en faisant son march dans nos propositions.
2.1 D FINIR
LES ACTIVITS , LES OBJECTIFS ET LES PRIORITS
Pour la prise en compte de lenvironnement, il est recommand de travailler avec la direction de

lorganisation pour dterminer au mieux les activits, les objectifs et les priorits daudit et de
contrle qui pourraient tre appuys par des logiciels.
Objectifs de
lorganisation
Objectifs
du service
Plus-value dun
support logiciel ?
oui
Entamer une
expression de
besoins de logiciel
non
Rflchir dautres
vecteurs damlioration
Logique besoins / objectifs
IFACI
14
Exemples dlments de contexte prendre en compte :

Une organisation trs dcentralise avec de nombreux utilisateurs, disperss dans 40 pays.
Dans ce contexte, les questions se poser pourront tre :
- Loutil donnera-t-il la possibilit chaque utilisateur de crer ses intituls de risque,
de spcifier ses contrles, des processus ? Ces fonctionnalits sont-elles accessibles
tous les niveaux de lorganisation de faon simple et rapide ?
- Sera-t-il possible de travailler avec plusieurs langues ?
- Le nombre dutilisateurs ne diminuera-t-il pas les performances de loutil avec par
exemple des lenteurs quand plusieurs personnes se connecteront en mme temps ?
- Les utilisateurs pourront-ils bnficier dune formation claire et accessible ? (sur
place ? en e-learning ?)
- Comment sera gre la synchronisation des documents lorsque plusieurs personnes
travailleront sur une mme source ?
- Etc.
Une organisation trs centralise avec 10 utilisateurs tous bass Paris. Dans ce contexte, le
workflow pourra tre trs normalis avec moins de champs libres que dans le cas prcdent
et des besoins moins contraignants en termes dergonomie, etc.
Un outil logiciel nest pas, dans notre contexte, un objectif, mais un moyen, une solution possible.
Etre attentif identifier des projets en synergie, afin de mutualiser les cots. Par exemple, le
dploiement dun outil support laudit interne peut faire partie dun projet plus global comprenant la gestion des risques et le support au contrle interne.
Risque
Rponses
Besoins non clairement exprims.
Rdiger un business case.
Manque de validation par les bons acteurs, au

bon niveau.
Implication du comit de pilotage.
Cot sous-valu.
Prendre en compte le cot total =

projet informatique
+ licences
+ infrastructure
+ formation initiale
+ formation spcifique administrateur
+ migration de donnes
+ prestataire interne informatique
+ temps des ressources internes
IFACI
15
A ce stade, on peut noncer trois remarques importantes, permettant dappliquer tout projet
informatique le scepticisme professionnel normalement dploy par tout auditeur dans ses travaux.
La rgle des pourquoi (au minimum trois) est appliquer. Cette rgle sert sassurer que
les besoins exprims sont suffisamment clairs, ne sont pas redondants, et reposent sur de
vritables objectifs. (cf. 3.1 Partir des besoins pour orienter les choix , p. 19).
Les objectifs multiples sont viter, et les buts contradictoires sont surveiller.
L'exprience prouve que les personnes investies dans un projet ne sont vritablement performantes que sur un seul objectif. Or, on assigne gnralement aux projets plusieurs objectifs, sans
les hirarchiser, qu'ils concernent la couverture fonctionnelle, la fiabilit, la scurit, le temps de
rponse, les charges et les dlais, etc.
La plupart du temps, le projet est guid par les dlais ou par les budgets, les autres objectifs faisant
office de variables d'ajustement. Dans ce cas, la primaut des dlais ou des budgets conduit ne
pas suffisamment intgrer les besoins des utilisateurs et minimiser, voire ne pas raliser des
tapes clefs telles que le maquettage, les ateliers d'changes, ou les tests.
Un logiciel nest pas toujours la solution. En dautres termes, il ne faut pas que ltude se
limite la rationalisation dun choix initial plus ou moins avou, mais bien lobjectivation
des diffrentes options.
2.2 A PPRCIER LES RISQUES
LA MESURE DES BNFICES ATTENDUS
Toute utilisation de logiciel prsente des risques. Un logiciel peut poser plus de problmes quil
nen rsout, par exemple en ralisant des alertes inutiles ncessitant des contrles supplmentaires
de la part des utilisateurs. De mme, il faudra sinterroger pour savoir si les bnfices attendus des
logiciels daudit ou de contrle (par exemple, la rapidit dmission des rapports, le suivi des
recommandations directement par les oprationnels, une meilleure supervision des missions, la
consolidation automatiques des dficiences et des plans dactions, etc.) vaudront linvestissement
ralis (en termes financier, de temps, de pertinence des analyses ou encore de production dindicateurs).
De plus, outre le risque de stre tromp de cible ou doutil, il faut savoir que des difficults surgiront sur le projet, relatifs au paramtrage, la personnalisation, la formation des utilisateurs, la
maintenance et au changement de version. Dans ce cadre, les logiciels complexes sont souvent
difficilement rentabiliss.
IFACI
16
Les risques dun tel projet sont identiques ceux de nimporte quel projet de dploiement dapplication informatique (voir le vecteur 6 Matrise de la ralisation des projets en fonction des enjeux
mtiers de Gouvernance du systme dinformation : guide daudit / AFAI, IFACI, CIGREF).
Face aux risques identifis, on formalisera systmatiquement et rgulirement les actions mises en
place pour y remdier. Il sagit dobjectiver et de mmoriser le pourquoi ? dactions rpondant
aux risques un instant donn du projet. En effet, le pourquoi ? est souvent oubli en cours de
route. Ds lors, soit les actions perdent de leur sens, soit elles ne peuvent tre remises en cause
utilement.
La notion de jalon
Un lment essentiel de la conduite de projet est de savoir dterminer son tat davancement.
Comme les Romains lavaient compris, il ny a quun bon moyen de savoir o on en est, cest de
placer des jalons le long de sa route.
Un jalon doit nous permettre de dterminer un tat davancement sans ambigut.
On nutilisera donc pas un pourcentage des dlais initiaux ou de la consommation budgtaire, qui
ne nous disent rien sur ltat actuel de lavancement. Pour reprendre une analogie routire, pour
savoir o lon en est, le compteur kilomtrique ou la jauge dessence ne sont que des pis-aller.
Un jalon est donc une tape sur laquelle, normalement, on na pas revenir. Ce sera par exemple
lexpression des besoins finalise et valide. En effet, tant quelle nest pas valide, on pourra
toujours la remettre en question. On peut imaginer plusieurs niveaux de validation, comme par
exemple une validation des utilisateurs, une validation du donneur dordre, une validation par le
contrle qualit et, pourquoi pas, une validation par le prestataire charg de la ralisation du projet.
Chacune de ces tapes peut tre considre comme un jalon.
Il faut ainsi dcouper le projet en tapes claires, aux critres de fin sans ambigut.
Les grands jalons habituels de la gestion de projet sont :
linitialisation du projet, lorsque le budget pour ltape dexpression du besoin est accord ;
le cas chant, le choix dun conseil pour laccompagnement en amont (dfinition des
besoins, identification des solutions de march, mise en uvre dun appel doffre) ;
lexpression des besoins, valide par la matrise douvrage (les utilisateurs et le donneur
dordre) ;
le choix du logiciel (ou la dcision de faire) et, le cas chant, le choix de lintgrateur pour
le dploiement de la solution (paramtrage, tests, conduite du changement) ;
les tests dacceptation donnant le feu vert la mise en uvre ;
la mise en exploitation effective.
A lintrieur de chacune de ces tapes, on pourra identifier des jalons intermdiaires. On peut aussi
lotir le projet, suivant un axe (fonctionnel, gographique, produits traits, etc.) ou une combinaison
daxes.
IFACI
17
PARTIE 3
E XPRIMER
LES BESOINS
Lexpression des besoins doit tenir compte de lenvironnement, cest--dire des contraintes juridiques et rglementaires, de la stratgie de lorganisation, de ses valeurs, des exigences professionnelles et des exigences lies aux diffrents mtiers et activits.
IFACI
18
3.1 PARTIR DES
BESOINS POUR ORIENTER LES CHOIX
Les besoins spcifiques de lorganisation1 doivent guider la slection des outils informatiques. Sil
est tentant pour les responsables de service de croire que lachat dun logiciel rsoudra leurs
problmes, il faut savoir que, frquemment, les auditeurs et contrleurs internes ne parviennent
pas utiliser correctement leurs logiciels. La raison en est simple : loutil choisi ne convient ni aux
objectifs, ni au primtre, ni lorganisation du service daudit ou de contrle internes.
Ainsi, il faudra veiller ne pas se laisser envoter par le discours des vendeurs, qui considrent que
leur logiciel rsoudra tous nos problmes, et nous font croire que le logiciel fera correctement et
aisment les choses.
Un logiciel nest pas meilleur quun autre : cest chaque gestionnaire de risques de
prendre le logiciel qui a la couverture fonctionnelle qui lui convient.
Depuis les dbuts de linformatique, on constate que tout projet comporte un risque important de
ne pas rpondre aux besoins.
En 2009, le Standish group2 constatait que :
seuls 32% des projets taient livrs dans le budget, les dlais et avec les fonctions demandes ;
44% des projets taient livrs et oprationnels, mais hors budget et dlais, et avec moins de
fonctionnalits que prvu ;
24% des projets avaient d tre arrts.
Cest pourquoi, tout projet informatique doit tre tudi avec la plus grande attention.
La premire tche, la plus difficile, consiste donc dfinir ses besoins. A cette tape, deux
cueils seront viter.
Les auditeurs et contrleurs internes nont pas connaissance de ce quils peuvent attendre
des outils informatiques. Ils ont ainsi tendance ne sintresser qu lautomatisation des
tches quils ralisent manuellement, limitant ainsi ltendue des possibilits qui leurs sont
offertes.
Lautre cueil consiste croire que, comme on ne connat pas vraiment ses besoins, on peut
sans risque prendre quelque chose de tout fait (un progiciel) qui nous permettra de dcouvrir des besoins auxquels on navait pas pens. Le risque est ici de se cantonner loffre sans
rflexion critique sur ses propres besoins.
1
La dmarche prsente est largement inspire de larticle, Choosing the right tool / Tim McCollum, David Salierno. - in Internal Auditor,
August 2003.
Le Standish group est une socit amricaine dont lactivit principale est de raliser des recherches sur les risques lis aux investissements
informatiques et aux moyens damliorer le retour sur investissement de tels projets. Sa particularit est de se concentrer sur les checs des
projets SI.
IFACI
19
Risque
Rponses
Manque de prcision dans la formulation des

besoins.
Passer par des maquettes et des prototypes.

Dialoguer avec des services dautres
organisations ayant rencontr une
problmatique similaire, par exemple par
lentremise dassociations professionnelles.
Indiffrence, voire rejet des utilisateurs, par

rapport la solution propose.
Faire des sessions participatives dexpression

des besoins et de conception.
Expliciter la plus-value attendue pour les
utilisateurs.
Insister sur lergonomie de la solution (design,
simplicit dutilisation) afin de faciliter son
appropriation par les utilisateurs.
Rexaminer et reprciser l'opportunit du
projet.
Nous tions la recherche d'une solution fiable et flexible qui rponde nos besoins actuels mais
qui soit galement capable d'accompagner les dveloppements que nous projetons court et moyen
termes. La puissance fonctionnelle de l'outil, ses capacits de reporting ainsi que ses qualits ergonomiques ont t les critres dterminants dans notre choix car l'acceptation de la solution par l'utilisateur est pour nous essentielle.
Directeur du Contrle Interne de lindustrie commerce - service
Concernant les exigences fonctionnelles, il faudra les passer au tamis dune analyse de la valeur. Si
on na ni les moyens, le temps ou la comptence pour dployer une telle technique, il faudra systmatiquement appliquer sur chaque fonction demande la rgle des 3 pourquoi (cf. encadr cidessous). Il restera ensuite savoir si la demande peut tre simplifie (le plus souvent en faisant
voluer le processus cible). Enfin, il est recommand de distinguer, dans lexpression des besoins,
les fonctionnalits essentielles de celles qui ne le sont pas.
Le souhait de mettre en place une solution informatise doit provenir du besoin de rsoudre un
problme, une difficult, damliorer un processus existant.
Exemple simplifi dapplication de la rgle des 3 pourquoi
Pourquoi vouloir mettre en place une solution logicielle intgre ?
Il faut un progiciel intgr, parce que cela permet dtre plus performant.
Pourquoi un logiciel intgr permet-il dtre plus performant ?
Parce quil permet de faciliter la supervision des activits au sein du service.
IFACI
20
Pourquoi un logiciel intgr facilite-t-il la supervision des activits au sein du service ?

Parce quun logiciel intgr nous permettrait d'tre dans un cadre mthodologique qui s'imposerait
tous.
Etre dans un cadre mthodologique qui s'impose tous est un objectif qui va pouvoir
tre dclin en attentes, critres d'atteinte, moyens ncessaires, risques ne pas faire, etc. Il
faudra ici tre attentif ce que la mthode porte par le progiciel n'impose pas aux utilisateurs des contraintes contre-productives car trop dcales par rapport la ralit des
missions confies.
Parce quun logiciel intgr permet de gnrer des tableaux de bord et que les dlais de ralisation
des activits pourront tre mieux surveills.
Parce quun logiciel intgr permet dobtenir une traabilit des preuves homogne et systmatique.
Il faudra s'interroger pour dterminer si la ralisation de ces objectifs ne serait pas mieux
matrise par la mise en place de dispositifs oprationnels moins onreux qu'un dploiement de logiciel.
La rception est la deuxime tape utilisateur la plus importante aprs lexpression des
besoins. Il est important de concevoir ds lamont du projet les tests de rception et leur droul.
A cet gard, pour chaque exigence de la phase Expression des besoins , il faudra fournir la
rponse la question comment tester cette exigence ? . Ne pas pouvoir y rpondre entranera
une remise en cause de la formulation de lexigence correspondante.
Besoins
Revoir la formulation
Formulation
des besoins
Le besoin
est-il testable ?
NON
OUI
Formulation
des tests
Continuer exprimer les besoins

IFACI
Besoins et tests de rception sont lis ds lamont
21
Risque
Rponses
Plan de test non appropri.
Elaborer des plans de test pour dtecter des

erreurs, pas pour prouver que a marche.
Anticiper les dlais ncessaires pour corriger
les anomalies dtectes lors des tests.
Plan de test trop linaire.
Construire un plan de test logique et

imaginatif.
3.2 L ES B ESOI NS LES

D AUDIT INTERNE
PLUS COURAMMENT INFORMATISS
EXEM PLE D UN SERVICE
Il existe la disposition de laudit tout un ensemble d'outils informatiques sur chaque phase ou
fonction :
Pilotage du service
Etape prliminaire
Outils de requtes et collecte dinformation, outils daccs

Internet, etc.
Conduite de mission
Outils de restitution.
Outil de production des rapports (avec la ncessit de bien vrifier
le niveau dintgration avec la suite bureautique de Microsoft qui
savre, dexprience, tre un point faible de nombreux progiciels
daudit).
La gestion du suivi des plans daction.
Outils de gestion documentaire.
Outils de planification.
Outils de gestion de papier de travail.
Travail terrain
Outils de dtection danomalies, de fraudes, etc. bass sur lanalyse

de donnes nombreuses ou des techniques dchantillonnage.
Outils de calculs et de comparaisons pour raliser des tests analytiques et statistiques.
Outils pour rechercher et croiser des informations.
Etc.
Communication
Production des rapports.

Suivi des plans daction.
IFACI
Outils de gestion du plan daudit.

Outils de gestion des ressources.
Outils de suivi des recommandations.
Gestion du suivi des plans daction.
Production dindicateurs et de tableaux de bord.
22
3.2.1 Pilotage du service

Gestion du plan d'audit
La gestion du plan d'audit comprend les phases d'laboration et de maintenance du plan. Les
diffrents intrants sont donc nombreux et complexes (analyses de conjecture, analyses de risques,
gestion des ressources, contraintes budgtaires, etc.).
Pour rpondre un besoin concernant la gestion du plan d'audit, les services daudit interne se
retrouvent face l'alternative de choisir entre :
un logiciel intgr, dont les modules vont rpondre de manire htrogne aux besoins du
service selon leur capacit intgrer facilement les diffrents intrants de llaboration du
plan, et
de multiples logiciels spcialiss (gestion des risques, gestion des ressources, gestion du
plan stricto sensu, gestion des plannings, etc.) pour lesquels il faudra acqurir et maintenir
l'expertise et grer les interfaces.
Gestion des ressources (plannings)

La plupart du temps le service daudit pourra se satisfaire doutils bureautiques ou, mieux, du logiciel de gestion de ressources en usage dans son organisation.
Automatiser la gestion des ressources par un outil spcifique pour le service daudit interne peut
cependant savrer ncessaire dans le cadre, par exemple, dun service de l'audit ayant des quipes
dissmines dans de multiples pays o sont rparties des expertises spcifiques. Ainsi, lancer une
mission ayant dans son primtre une technologie Y ncessitera de faire appel des auditeurs
des pays A , B et C . Pour optimiser les affectations, il faudra donc tenir compte des localisations, des expertises et des disponibilits, do le besoin dun outil adapt.
Gestion des recommandations

La gestion des recommandations est sans doute le dispositif dont lautomatisation se justifie quelle
que soit la taille du service et les contraintes de son environnement. Une gestion informatise des
recommandations peut s'inscrire dans plusieurs objectifs : le suivi de leur mise en uvre qui peut
s'avrer complexe, la recherche dune classification et dune homognisation de la formulation des
recommandations, la mise en lumire de faiblesses gnriques, etc.
Par ailleurs, il faut galement prendre en compte le mode dorganisation, qui peut avoir des impacts
non ngligeables dans le choix de solution : organisation centralise ou dcentralise de la gestion
des recommandations pouvant mettre en jeu des filiales aux technologies fort diffrentes, suivi de
lavancement des ralisations des recommandations par un service distinct (par exemple, le
contrle des risques) du service daudit metteur de la recommandation, etc.
IFACI
23
3.2.2 Conduite de mission

Gestion des programmes de travail
La gestion des programmes de travail est gnralement automatise dans les services daudit effectuant majoritairement des missions rcurrentes cest--dire dont le primtre et lobjectif
peuvent tre rpts (revue complte dactivits, audit de conformit, etc.), avec des quipes
composes souvent dune part importante dauditeurs juniors.
La gestion des programmes de travail rclame de toute faon une animation importante pour capitaliser le retour dexprience, maintenir la base des programmes et laborer de nouveaux
programmes. Loutil logiciel ne peut pas se substituer ce dispositif de mise jour et de knowledge
management mais il en est un complment utile. Pour un certain nombre de travaux, ces
programmes de travail pourront tre tout simplement labors avec des outils bureautiques de base
(tableur et/ou traitement de texte).
Gestion des papiers de travail

Automatiser la gestion des papiers de travail est toujours un point sensible, car l'outil doit aider les
auditeurs rpondre leurs besoins de traabilit des preuves d'audit, sans pour autant alourdir
inconsidrment leur travail. Dans ce cas, le temps de gestion des preuves pourrait devenir suprieur au temps net d'investigation et d'laboration des preuves.
Les services d'audit interne peuvent se trouver dans les cas suivants :
si les audits de conformit sont majoritaires, le besoin de gestion se concentrera sur les
fiches de contrles. Dans ce cas, un outil bureautique est gnralement suffisant. On peut
aussi envisager un outil commun ou coupl entre la gestion des programmes d'audit et des
papiers de travail.
si les audits sont gnralement longs, brassant des centaines de documents et ncessitant
des dizaines d'entretiens, un outil spcialis s'avre vite ncessaire.
3.2.3 Travail terrain

Lanalyse de donnes
Rserve, usuellement, aux auditeurs ddis aux systmes d'information, son utilisation se gnralise avec la mise disposition de progiciels de plus en plus faciles dutilisation.
Sappuyant sur des donnes fiables, jour, dinterprtation non ambigu, lanalyse des donnes est
entirement tributaire de la qualit du systme d'information de lorganisation. Les possibilits les
plus communes sont les suivantes :
IFACI
24
dispositifs embarqus dans les programmes dapplication ;

outils intgrs ou modules dERP ;
suite externe de GRC ;
programmes spcifiques danalyse de donnes.
3.3 F ORMALISER LA
PHASE D EXPRESSION DES BESOINS
Ltat des lieux des besoins tant lune des tapes cls du projet, il convient de la formaliser et de
la justifier (cf. annexe 3 Etat des lieux des besoins , p. 56).
Un document de cadrage permettra lidentification la plus prcise possible des besoins fonctionnels
et techniques, y compris de lvaluation des contraintes et des priorits prendre en compte.
Un schma de fonctionnement des processus affects par le projet permettra de visualiser facilement les tapes cls, les acteurs et les points de contrle.
Dans une expression des besoins, il convient de distinguer plusieurs types dexigences :
Fonctionnelles. On va exprimer ici quelles fonctions on souhaite voir remplir par un logiciel.
Techniques. Ce point est particulirement sensible si on veut (ou doit) intgrer le logiciel
au systme d'information de lorganisation. Par exemple, le logiciel doit imprativement
tourner sur un systme dexploitation prcis, disposer de tel type de base de donnes, ou
encore tre compatible avec loutil de gestion des profils de scurit de lorganisation.
Organisationnelles. A minima, il faudra ici dcrire lorganisation cible. On peut par exemple tre rattach une partie dun service daudit dont les services sont rpartis sur lEurope.
Ces services doivent non seulement communiquer entre eux mais, par exemple, partager
des papiers de travail en temps rel sur une mission donne. On voit donc que les pratiques
et les choix dorganisation doivent tre explicits, car ils auront une incidence sur lapprciation que lon pourra porter sur la capacit dun logiciel rpondre aux besoins exprims.
Quantitatives. Trs souvent en complment aux contraintes techniques, on explicitera les
lments qui ont un impact sur la performance et la capacit de charge du logiciel, comme
le nombre de personnes devant se connecter, les temps de rponse esprs, etc.
Qualitatives. On parle aussi dexigences non fonctionnelles, sur le modle de lISO
9126-1:2001 Gnie du logiciel Qualit des produits. Par exemple, on pourra prciser ses
exigences en termes de lisibilit de la documentation utilisateur, dergonomie du logiciel, de
facilit dapprentissage ou encore de facilit de maintenance.
De scurit. Les organisations disposent le plus souvent d'une dmarche permettant de
dfinir les exigences de scurit des logiciels. L'tat de l'art veut qu'au moins trois facteurs
de scurit soient dfinis : l'intgrit des donnes et des traitements, la confidentialit de
IFACI
25
l'information et la disponibilit des donnes et des traitements. De plus, pour les logiciels
de support aux services daudit et de contrle internes une attention particulire est porte
la qualit de la piste daudit.
Juridiques et rglementaires. Ces exigences sont gnralement centres sur les prescriptions de la CNIL, ds qu'il s'agit de gestion informatise. Il faudra bien sr prendre aussi en
compte les rglementations spcifiques au secteur d'activit de lorganisation.
Le choix du logiciel est un travail dquipe au sein du service daudit ou de contrle interne. Il doit
en effet impliquer au plus tt les futurs utilisateurs pour faciliter la slection des besoins les plus
pertinents et la conduite du changement. Lorganisation de sessions participatives dexpression des
besoins est un facteur cl de succs (cf. annexe 2 Organisation de sessions participatives dexpression des besoins , p. 54). Elles peuvent sappuyer sur des dmarches telles que le JRP (joint requirements planning) dvelopp en annexe 2. La mthode retenue dpendra de la taille et de la
complexit du projet.
XXX permettra une gestion des alertes automatiques sur l'avancement du portefeuille de
missions et optimisera la scurit au niveau des oprations menes par nos auditeurs
internes. De plus, les capacits de l'outil couvrir les principaux besoins dfinis par l'audit
interne, la souplesse de paramtrage ainsi que la politique produit innovante de XXX sont
autant de raisons qui nous ont confortes dans ce choix stratgique.
Directeur de laudit interne
XXX est l'outil stratgique centralisateur qui permettra de fiabiliser la couverture des
risques et d'en assurer la cohrence. Nous avons slectionn cette solution car notre stratgie consiste non seulement automatiser les procdures de contrle interne mais galement
mettre la disposition des correspondants risques et contrle interne une solution facile
d'utilisation, ergonomique et fiable. XXX offre une grande libert d'utilisation et une
matrise des risques depuis les objectifs stratgiques de l'entreprise jusqu' la mise sous
contrle priodique ou permanent de ses activits oprationnelles.
Responsable du Contrle Interne
IFACI
26
PARTIE 4
L A DMARCHE
IFACI
DE SLECTION
27
Ltat des lieux des besoins a permis ltablissement de documents de rfrence (document de
cadrage, cartographie des processus, description des besoins fonctionnels et techniques, etc.)
utiliser pendant la phase de slection qui est aborde en trois squences :
lanalyse des options au regard des besoins identifis ;
lanalyse des solutions du march lorsque loption retenue consiste acqurir un logiciel.
Cette squence se conclut gnralement par ltablissement dun cahier des charges dfinissant les critres de consultation et de slection. Ces critres vont au-del de laspect
fonctionnel et permettent notamment de :
- prciser le primtre de la consultation. Inclut-il par exemple les plateformes techniques (serveurs, base de donnes et applications) ?
- dfinir les modalits de consultation au regard des contraintes de planning du service
et des procdures dachat ;
le choix de lditeur mme de dployer la solution souhaite. Les rponses des diffrents
diteurs sont values au regard des critres pralablement dfinis. Un nombre restreint
dditeurs sont invits prciser leur offre lors dentretiens oraux aboutissant au choix de
lditeur retenu.
Les sources dinformation pour identifier les acteurs pertinents sont diverses. Par exemple :
les socits comme CXP, Forrester Research, IDC, Gartner recensent les diteurs ;
Internet (site des diteurs, articles et autres sources) ;
les analyses des associations professionnelles (cf. bibliographie) ;
les retours dexpriences.
Dans le cadre de cette slection, il est important de ne pas se restreindre aux seuls leaders du
march, habituellement les plus cits. Les acteurs de niche, par exemple, peuvent proposer des
solutions pertinentes parfaitement adaptes certains contextes et parfois un cot comptitif.
Dautres acteurs peuvent proposer des solutions innovantes (outil innovant de contrle continu,
systmes experts danalyse des risques) (cf. annexe 6 Outils daudit et de contrle en continu ,
p. 69).
Il convient aussi dans le cadre de lvaluation des diteurs dvaluer la capacit de lditeur dlivrer, mais aussi maintenir la solution propose dans le cas dun dploiement dune solution qui
aurait une complexit ou une taille particulirement importante.
Enfin, il est fondamental davoir des dmonstrations de chaque solution slectionne dans la liste
restreinte sur la base dun scnario le plus proche possible de nos propres besoins et processus
cibles, et dobserver que les fonctionnalits sont effectivement existantes et adaptables notre
environnement.
IFACI
28
4.1 E TUDIER
4.1.1
LES OPTIONS
De nombreuses options possibles
Face un besoin dinformatisation, les utilisateurs ont une plthore doptions possibles, illustres
dans le schma ci-dessous. Pour ne pas compliquer le schma, nous navons pas fait figurer les relations transverses entre les options : par exemple, un service daudit peut se retrouver utiliser un
logiciel de lorganisation sous la forme dun outil intgr (GRC), dj utilis par le contrle des
risques.
Etudier les options
Utiliser les
logiciels de
lorganisation
Logiciels
bureautiques
Outils
collaboratifs
Dveloppement
spcifique
Progiciels
spcialiss
Intgrs
(GRC)
Ddis
Typologie des options
Nombre de services daudit ou de contrle utilisent des bases de donnes bureautiques ou des
tableurs. Il faut bien savoir que ceux-ci ont des limites et que vouloir leur faire faire plus que ce dont
ils sont capables en standard pourra coter cher en termes de maintenance ou de fiabilit des
outils. Cette approche pourrait galement avoir des consquences sur la qualit de la preuve daudit. Si leurs limites sont correctement prises en compte, les tableurs peuvent tre utiliss, par exemple, pour les analyses de rgression, de ratio, de tendances ou de mesures de la performance.
Si les auditeurs ou contrleurs ont besoin doutils plus puissants ou sophistiqus, ils devront
dabord sintresser aux outils en place dans lorganisation pour la gestion des bases de donnes
(outil de requtes) et/ou la gestion des processus (par exemple, les ERP) et ventuellement, songer
lajout de modules complmentaires.
IFACI
29
Privilgier l'existant et les logiciels libres

Les outils logiciels de laudit ou du contrle doivent sinscrire dans lenvironnement technologique
de lorganisation. Les outils bureautiques, les utilitaires existants dans les bases de donnes de lorganisation ou ses ERP peuvent ainsi tre utiliss, ce qui permet dviter lachat dun logiciel.
Si les outils disposition ne permettent pas de rpondre aux besoins, la solution retenir devra tre
intgrable dans larchitecture technique. Pour ce faire, la slection, lvolution, la scurisation
devront correspondre aux standards informatiques de lorganisation.
Naturellement, il faudra sinscrire dans les dmarches utilises par lorganisation dans la conduite
de ses projets.
Enfin, le service daudit ou de contrle interne doit tre la matrise douvrage du projet, cest--dire
le donneur dordre.
Dans le numro d'aot 2004 d'Internal Auditor, l'article1 consacr lenqute annuelle sur les outils
daudit prconisait dj de voir si les logiciels en place dans les services oprationnels ou de
contrle de gestion (par exemple) ne pouvaient pas tre rutiliss par l'audit (IDEA, ACL, SAS et
les outils bureautiques comme ACCESS ou EXCEL en sont des exemples).
Cet article souligne aussi la qualit professionnelle des logiciels libres et prconise aux auditeurs en
qute dun outil notamment pour des audits de scurit des systmes dinformation de regarder
vers les logiciels libres avant denvisager une solution commerciale.
On trouvera facilement aussi, disposition sur Internet, des feuilles EXCEL prprogrammes pour
faire des travaux analytiques (ratios, tendances, tirage alatoire et analyse statistique).
Mais les auditeurs ou contrleurs pourront prfrer des outils spcifiques quils auront dvelopps
ou fait dvelopper, par exemple dans le domaine de lanalyse des risques, la dtection des fraudes
ou lautomatisation des papiers de travail.
Dans notre groupe industriel de taille moyenne (25 000 personnes dans 40 pays) nous avons dvelopp en interne un outil de suivi des missions et de suivi de la mise en uvre des recommandations.
Cet outil permet :
de scuriser les donnes (sauvegarde quotidienne, gestion des droits daccs) ;
dobtenir instantanment toutes les statistiques ncessaires au suivi oprationnel de notre activit
ainsi que pour la prparation des diffrents rapports dactivit (direction gnrale, COMEX, comit
daudit) ;
denvoyer rgulirement aux parties prenantes (directions de zone, directions fonctionnelles, etc.)
des tats de suivi des recommandations dans leur zone de responsabilit respective.
Lavantage du dveloppement en interne est, dune part, une conomie de cots, dautre part, une possibilit
de faire voluer loutil en fonction de nos besoins de faon rapide. Cela ncessite par contre une bonne et
troite collaboration avec la direction informatique pour obtenir les ressources ncessaires.
Get the most out of audit tools / Russel A. Jackson. - in Internal Auditor August 2004.
IFACI
30
4.1.2 Les solutions logicielles les plus couramment utilises

Afin de supporter, totalement ou partiellement, les diffrentes activits des services daudit et de
contrle internes dcrites plus haut, diffrentes technologies sont aujourdhui disponibles. La typologie suivante permet de classer les diffrentes solutions logicielles existantes.
Les solutions proposes ne sopposent pas ncessairement. Par exemple : les outils bureautiques
peuvent tre supports par des outils collaboratifs permettant la gestion des versions et des flux de
validation.
4.1.2.1
Les outils bureautiques sur serveurs partags
Outils populaires par excellence et dj utiliss par lensemble des services, les outils de type
bureautique, permettent de supporter des activits essentielles comme la gestion des programmes
de travail, la gestion du planning, la gestion des recommandations, la gestion des connaissances,
etc.
Dans ce cadre, des fichiers modles sont mis disposition des utilisateurs sur des serveurs de
fichiers partags, afin dhomogniser et standardiser la constitution des diffrents documents de
travail. Lensemble des papiers de travail labors pour une mission donne est stock dans une
arborescence de rpertoires cre pour les diffrentes missions daudit.
La gestion des recommandations ncessite la constitution dune base de donnes pour permettre
de documenter le suivi dans le temps de la mise en uvre. Ces bases peuvent tre constitues
galement sur des outils des suites Microsoft Office ou OpenOffice par exemple.
La gestion du planning peut galement tre supporte par un fichier de type tableur, stock sur le
serveur partag.
Si tout se droule correctement, on pourra profiter dun ou de plusieurs des avantages suivants :
cot de dveloppement et de formation trs faible (facilit dutilisation) ;
cot dexploitation trs faible (pas de cot supplmentaire de licences en gnral), limit au
cot de stockage sur des serveurs ;
stockage centralis des documents rcolts et produits pendant les missions ;
rapidit de dploiement.
Il faut nanmoins souligner les cueils les plus communs :

partage des documents pendant les missions difficile garantir ;
indicateurs de performance mis en place manuellement, donc coteux maintenir et peu
fiables ;
gestion de la scurit daccs aux informations difficile maintenir ;
IFACI
31
manque de fiabilit des donnes de reporting ;

gestion documentaire et gestion des connaissances limites ;
maintenance et volution, comme pour tout outil bureautique, sont dlicats grer.
En conclusion, cette solution est typique dun service daudit ou de contrle internes de taille
rduite et dans un lieu unique. Elle devient rapidement un obstacle la standardisation, la productivit et la qualit pour des services de taille significative et multi-sites.
4.1.2.2
Les outils intgrs
Depuis une quinzaine dannes, des solutions intgres sont proposes par des diteurs spcialiss,
permettant de supporter quasiment lensemble des processus de laudit interne et du contrle
internes. Loffre est aujourdhui plthorique avec toutefois des disparits fonctionnelles, ergonomiques et technologiques fortes. Le choix et la mise en place dune telle solution ncessite que le
service daudit ou de contrle internes lance un vritable projet.
standardisation et gestion de la qualit des missions ;
possibilit de gestion de connaissances (base documentaire) ;
constitution automatique des indicateurs oprationnels (suivi des missions), et de performance ;
automatisation des flux de gestion documentaires incluant la rvision et lapprobation ;
fiabilisation des processus daudit et de contrle ;
gestion fine de la scurit daccs ;
fiabilisation de la sauvegarde et du stockage de donnes.

comptences ncessaires insuffisantes en gestion de projets;
cot du projet (ventuels dveloppement spcifiques, paramtrages), des licences et de la
maintenance (changement de versions et volutions) ;
cot de la formation ;
relation fournisseur grer ;
ncessit davoir des administrateurs du logiciel.
Ce type de logiciel correspondra tout particulirement un service de contrle interne et daudit

interne voluant au sein dorganisations disposant de ressources et moyens suffisants leur permettant de rpondre aux besoins en termes de gestion de projet et de maintenance. Dautre part, ce
type doutils peut tre un vritable atout pour permettre aux processus mtiers dtre les plus
performants, et conformes aux normes qualit de rfrence.
IFACI
32
Les outils intgrs peuvent servir une multiplicit dacteurs, tels que laudit interne et laudit
externe pour le suivi de leurs recommandations ; laudit, le contrle interne et/ou le gestionnaire
des risques pour le partage dun rfrentiel commun, cartographies, suivi des plans dactions, etc.
Cette opportunit doit tre prise en considration ds la phase de dfinition des besoins et pour le
choix de la solution qui pourra tre volutive pour ventuellement, terme, stendre dautres
acteurs.
Cette volutivit pourra galement se traduire au niveau des modules slectionns. Le service
pouvant choisir tout ou partie des modules gnralement proposs : gestion du planning, documentation des papiers de travail, suivi des recommandations et plans dactions, etc.
4.1.2.3
Les outils collaboratifs
Une alternative ces outils intgrs, dont les cots peuvent savrer prohibitifs pour certains
services daudit interne, est aujourdhui propose par les outils de type collaboratif, dont les fonctionnalits sont de plus en plus riches.
Ainsi, les plateformes Lotus Notes, TeamPlace ou Microsoft Sharepoint prennent en compte le
besoin de structurer les informations stockes classiquement sur des serveurs de fichiers. Elles
permettent aujourdhui dimplmenter des fonctionnalits de gestion documentaire, de planning,
etc., tout en supportant les mcanismes de workflow pour la rvision et lapprobation de documents.
cot modr de personnalisation ou de paramtrage des plateformes, voire faible si les
fonctionnalits restent basiques ou existent dj dans lorganisation ;
cot dexploitation et de formation faible ;
cot supplmentaire de licences et de maintenance faible, voire nul ;
accs multi-sites ;
gestion de la scurit daccs fine ;
intgration facilite aux intranets dentreprise.

dveloppements spcifiques raliser ou faire raliser, pouvant savrer complexes et
coteux pour des fonctionnalits volues ;
dpendance forte vis--vis de lditeur (prennit de la maintenance de la plateforme) et
la DSI interne de lorganisation ;
cela sajoutent les inconvnients identifis supra pour les outils bureautiques (sans les
inconvnients du partage de documents).
IFACI
33
Ces outils ne remplacent pas les outils intgrs, mais permettent tout de mme de rpondre aux
besoins de stockage des documents, dautomatisation et de traabilit des validations et tout
simplement de partage de savoir. Ce type doutil est rpandu actuellement au sein des services
daudit interne dans le cadre de la gestion de la mission daudit (mme de groupes de taille importante).
4.1.2.4
Les outils ddis
Il y a une application pour peu prs tout .

Un service daudit ou de contrle internes peut avoir besoin de mettre en uvre des fonctionnalits
spcifiques (gestion des comptences1, gestion du planning, suivi des recommandations) sans avoir
lusage dun logiciel intgr.
Lutilisation doutils ddis pour rpondre des besoins cibls (ex. : MS Project pour la gestion du
planning) prsente les avantages potentielles suivants :
cot de licences modr, voire nul ;
cot de personnalisation ou paramtrage modr, voire faible si les fonctionnalits de paramtrage restent basiques ;
cot dexploitation et de formation faible ;
rponse prcise aux besoins.

complexit dintgration avec les autres applications prsentes et utilises au sein de lorganisation ;
gestion de la scurit daccs aux informations dlicate garantir.
En conclusion, le choix doutils ddis est une option permettant de rpondre un besoin prcis
avec un investissement modr dans le court terme. Toutefois, la dmultiplication doutils ddis
au sein du service entranera des difficults dintgration (pas de partage des donnes rfrentielles, lesquelles devront tre maintenues dans diffrents outils).
Les avantages et inconvnients sont ainsi analyser en fonction du contexte, de la complexit de
lorganisation et/ou des missions.
Etant entendu que la DRH ne mette pas dj disposition un outil de gestion des comptences.
IFACI
34
4.2 E TUDIER L OFFRE COMMERCIALE

Dans la suite du document, laccent sera mis sur la slection dun progiciel spcialis.
De nombreuses applications proposes par des diteurs sont susceptibles de rpondre aux diffrents besoins des professionnels de laudit et de la matrise des risques.
Pour rpondre leur besoin damlioration de leur niveau de contrle interne, de nombreuses
organisations ont adopt le modle GRC (Governance, Risk and Compliance).
La GRC se dfinit comme une structure intgre permettant dunifier et les fonctions gouvernance,
risques, contrle et conformit, travers lorganisation.
La GRC est une approche oriente processus, elle permet didentifier les risques au sein dun
processus, de dfinir des normes au sein de ces processus, afin de mettre les risques sous contrle.
Lapproche GRC permet :
de librer davantage de valeur ajoute par la rationalisation de la ralisation des contrles
et une gestion des cots plus efficiente ;
de capitaliser sur les opportunits et minimiser les pertes travers une gestion des risques
et de processus de prises de dcision optimiss ;
davoir une vision plus transparente et plus proche du temps rel du statut des risques
travers les tableaux de bords des outils de GRC ;
de structurer et de surveiller le dploiement de lapproche de gestion intgre des risques
supporte par loutil.
Les outils de GRC du march ont donc volu dune approche initialement plus tourne vers la
conformit, vers une approche davantage oriente vers la gestion des risques de lorganisation.
Cette dernire prenant galement en compte les aspects lis la gestion de la performance des
processus et du pilotage.
La socit Gartner considre comme faisant parties du secteur des systmes de GRC
(Gouvernance, Risques, Conformit), les diffrents logiciels proposant les fonctionnalits cls suivantes :
gestion de laudit : support des quipes daudit interne dans le cadre de la
gestion des papiers de travail, des plannings et du reporting ;
gestion des politiques et procdures : gestion du cycle de vie des procdures et
leurs validations ;
conformit : gestion de la documentation des contrles, des risques, des autovaluations, des tests et suivi des plans daction ;
gestion des risques : support la gestion du risque avec sa documentation, flux
de validation, valuation et analyse, reporting, cartographie et remdiation
des risques.
Ils intgrent dsormais des fonctionnalits de conception de processus mtiers, de
contrle continu, danalyse des risques (cf. annexe 6 Outils daudit et de contrle en
continu , p. 69).
IFACI
35
Notons nanmoins que limplantation dun outil de GRC peut tre source de lourdeur et de
complexit sil sagit de dployer un simple outil de management des services daudit et de contrle
internes qui ne viendrait pas en appui dun vritable dispositif de gestion intgre des risques. En
effet, la complexit intrinsque la mise en uvre de ce type doutil est amplifie par les trois
objectifs viss et laugmentation du nombre dacteurs impliqus.
Gartner Research1 dfinit les catgories dditeurs de GRC de la manire suivante :

les Leaders sont les acteurs majeurs du march international de la GRC (en termes de
parts de march et de nombre de clients). Leurs solutions couvrent les fonctionnalits
gouvernance, audit, gestion des risques, contrle interne. Lensemble des utilisateurs
(cadres, auditeurs et managers) disposent dune vue densemble en termes de risques et de
conformit, quelle que soit lorganisation de lentreprise. Par exemple, BWISE,
MetricStream, Openpage (IBM), Oracle GRC, SAP GRC, Thomson Reuters (Paisley), etc. ;
les Visionnaires proposent des solutions prsentant des domaines dexpertises sur
certaines fonctionnalits et amliorent la couverture fonctionnelle des solutions. Par exemple : Enablon, Mega, SAS, etc. ;
les Challengers sont des acteurs disposant dune bonne prsence sur le march mais ne
disposant pas dune solution couvrant totalement les fonctionnalits gouvernance, audit,
gestion des risques, contrles internes. Par exemple, Protiviti ;
les acteurs de niche proposent une approche unique du march GRC, mais sans pour
autant proposer lensemble des fonctionnalits GRC. Par exemple, Wolters Kluwer.
Le Gartner Research, en octobre 2012, considrait que les solutions proposes sur le march de la
GRC avaient atteint une maturit en termes de couverture fonctionnelle ; la diffrenciation entre
les solutions se fait dsormais sur les fonctionnalits de gestion de risques et de la prise en compte
des impacts de ces risques sur la performance de lorganisation.
Il convient de noter que le march franais prsente plusieurs diteurs majeurs de solutions GRC
que sont Enablon, eFront et RVR (Devoteam).
Gartner Research est une socit de recherche et de conseil amricaine spcialise dans les nouvelles technologies. Elle propose notamment
des quadrants permettant de comparer le positionnement des diteurs de logiciels.
IFACI
36
On peut citer les diteurs suivants1 qui proposent des solutions pouvant couvrir des besoins des
services daudit et du contrle internes :
Bwise (Nasdaq OMX)
Bwise GRC
Cura Software solutions
Cura Enterprise GRC platform
Devoteam
RVR Risque, Contrle, Audit
eFront
Front GRC
EMC
RSA Archer Egrc
Enablon
Enablon GRC
IBM
OpenPages GRC
MethodWare (Jadesoftware)
ERA Kairos 8.1
Magique Galileo
Risk and Audit Management Software
Mega
Mega Suite 4.0
MetricStream
Audit Management Solution and GRC Platform 6.0
Mkinsight
Audit & risk management solutions
Oracle
Fusion GRC Suite
Oxial
Risk Management Solution
Pentana
PAWS Audit & Risk Management Software
Protiviti
GRC software
ROK
ROK solution
RunBook
Internal Control
SAP
GRC
Software AG
Aris R&C Manager 4.0
Sword Achiever
Sword Achiever 5
Symbiant
Symbiant Risk Suite and Symbiant Tracker
Thomson Reuters
Accelus (GRC - Paisley)
Wolters Kluwer
ARC Logic suite (CCH TeamMate, FRSGlobal)
Voir galement le dossier Etat des lieux des outils informatiques disposition des auditeurs - revue Audit & Contrle internes, n212,
dcembre 2012.
IFACI
37
Dautre part, les diteurs suivants proposent des solutions permettant danalyser les donnes (cf.
annexe 5 Lanalyse des donnes , p. 68) et des outils daudit et de contrle en continu (cf. annexe
6 Outils daudit et de contrle en continu , p. 69) :
ACL ;
Caseware (Idea) ;
Actimize ;
Datawatch ;
Greenlight technologies.
Quelques sources pour se faire une ide :

AMRAE, cahier technique Systmes dinformation de gestion des risques 2012
Gartner Research, Magic Quadrant for Enterprise Governance, Risk and Compliance
Platforms October 4, 2012
Forrester Wave: Enterprise GRC Platforms, Q4 11
IT project management / Shannon Buckley. Internal auditor, august 2011.
Leveraging data analysis software / Norman Marks. - Internal auditor, august 2009.
An array of technology tools / Glen L. Gray. - Internal auditor, august 2006.
Opening the door / Neil Baker. - Internal auditor, august 2005.
Get the most out of audit tools / Russell A. Jackon. - Internal auditor, august 2004.
Dans les solutions informatiques la disposition des services daudit ou de contrle, on peut trouver des offres de SaaS. Cet acronyme barbare signifie Software as a Service, cest--dire que, moyennant rtribution, un oprateur met votre disposition des logiciels mais aussi leur maintenance,
leur exploitation, les ressources informatiques ncessaires et ce pour un niveau de service dfini
contractuellement.
Loffre SaaS est en fait une des options commerciales1 de ce que lon appelle le Cloud Computing,
cest--dire linformatique dans les nuages .
Pour lutilisateur, linformatique dans les nuages peut tre caractrise2 par 4 lments :
la transparence des infrastructures et du matriel ;
laccs immdiat aux ressources ncessaires ;
la cohabitation, au sein dune mme structure dmatrialise, de nombreux usagers ayant
la garantie de la scurit de leurs donnes ;
le paiement en fonction de la consommation relle.
Linformatique dans les nuages repose techniquement sur la virtualisation des serveurs et lutilisation de rseaux de tlcommunication performants. Les ordinateurs supportant ces serveurs virtualiss sont hbergs dans des centres de calculs dont la rpartition gographique est fonction des
Outre le SaaS, les deux autres principales options commerciales sont : IaaS (Infrastructure as a Service) et PaaS (Platform as a Service). Ces
dernires options ne sont bien videmment pas lusage direct de lutilisateur final.
Linformatique dans les nuages (ou le cloud computing). in Cfdt magazine, n 366 de septembre-octobre 2010.
IFACI
38
intrts du fournisseur. En clair, lutilisateur ne sait pas o se trouvent physiquement ses donnes
ni quelles lgislations elles sont soumises. De plus, les donnes traites par les oprateurs amricains dinformatique dans les nuages sont soumises au Patriot Act1, et donc transmissibles aux
autorits amricaines. Ainsi, les avantages immdiats pour lutilisateur peuvent cacher des problmatiques srieuses de confidentialit des donnes, par exemple. On consultera avec profit le site de
la CNIL sur ce sujet.
Au-del de la gestion des accs, lvaluation du logiciel devrait prendre en compte la confidentialit
des donnes et notamment leurs modalits de stockage. En particulier, la notion de cloud computing,
potentiellement incluse dans une offre commerciale plus globale, doit pouvoir tre identifie
compte tenu de son antinomie avec les besoins de confidentialit des donnes daudit.
4.3 E VALUER LES
PROGICIELS ET SLECTIONNER UN OUTIL
Il est indispensable dvaluer les progiciels selon diffrents critres et en fonction des besoins dfinis. Ces critres sont par exemple la simplicit dutilisation, la lisibilit des restitutions, la qualit de
la documentation, le support technique, la rputation du fournisseur, la gestion des versions, les
cots et, naturellement, la couverture fonctionnelle des besoins. Cette liste est loin dtre exhaustive (cf. annexe 4 Exemples de grille de slection , p. 61).
Dans le cas dun choix de progiciel, on peut regrouper les critres en trois catgories principales :
les critres lis lditeur mme ;
les critres lis aux spcificits du produit ;
les critres lis aux fonctionnalits en regard des besoins dfinis.
On formalisera ces critres de manire dtaille au sein dune matrice de slection (cf. annexe 4
Exemples de grille de slection , p. 61) qui prendra en compte la pondration de chacun dentre
eux, en fonction de limportance que lon souhaite leur donner.
A titre illustratif, les critres suivants seront trs gnralement pris en compte (liste non exhaustive
devant tre adapte chaque contexte).
1. Evaluation de lditeur (valuation de viabilit, de la vision, de lexprience)
a. Nombre de clients
b. Nombre de clients pour le produit en particulier
c. Nombre de clients pour le produit en France (si pertinent)
d. Nombre de rfrences dans mon secteur dactivit
e. Le systme peut-il tre dploy et maintenu en France ?
Les autorits US ont la main sur les donnes Cloud. in le Journal du Net (www.journaldunet.com), le 5 juillet 2011
IFACI
39
f.
Lditeur / le partenaire en charge de linstallation parle-t-il franais (en fonction des

contextes) ?
g. Liste des partenaires (si applicable)
h. Elments financiers concernant lditeur
i. Positionnement ventuel dans les bases des recherches. Identification de solutions
concurrentes
j. Lditeur montre-t-il de lintrt pour rpondre la consultation ?
k. Taille relative de lditeur et de lentit qui ralise lappel doffre.
2. Evaluation des spcificits du produit (qualit, stabilit, dploiement et cot)
a. Version du produit
b. CA moyen des clients
c. Nombre moyen dutilisateurs
d. Langage de programmation (standard, facilit de dveloppement spcifique)
e. Architecture (base de donnes, serveurs, cloud computing)
f. Internationalisation du produit (interface homme/machine unilingue ou multilingue)
g. Cot moyen des licences
h. Cot moyen de la maintenance
i. Cot moyen du dploiement (installation typique)
j. Disponibilit dun support client pour le produit (prendre en compte la problmatique
de la langue si pertinent)
3. Evaluation des fonctionnalits (adaptation aux besoins)
a. Le logiciel rpond-t-il aux besoins fonctionnels et techniques dfinis lors de la phase
prliminaire ?
b. Niveau de dveloppement ncessaire pour adapter loutil standard aux besoins (durant
la phase de dploiement)
c. Facilit dvolution de loutil aprs un premier dploiement
d. Gestion des accs et de la scurit
e. Facilit de connexion, ergonomie
f. Qualit de la documentation (langue, lisibilit)
g. Importation et exportation des donnes
Llaboration du cahier des charges permettra de dfinir les documents de la consultation :
dfinition de la matrice des critres de slection ;
formalisation des sections fonctionnelles et techniques ;
dfinition de scnario de prsentation (Proof of Concept).
Sur la base des documents de consultation diffuss et de lapproche de slection, il convient de
procder lanalyse comparative des propositions fournies par les prestataires slectionns et ayant
rpondu cette consultation.
IFACI
40
Outre les dossiers soumis par les diteurs, des entretiens pourront tre conduits sur la base des
scnarios dfinis durant la phase prcdente. Ces ateliers doivent permettre de mieux apprhender
les fonctionnalits et lenvironnement des solutions proposes, ainsi que les points dattention ou
les interrogations remontes lors de lanalyse des offres.
Un comit de slection pourra se runir pour statuer sur loutil retenir au vu de lanalyse comparative effectue et des conclusions des entretiens.
IFACI
41
PARTIE 5
M AQUETTER / DVELOPPER /
PARAMTRER
Compte tenu des besoins spcifiques chaque organisation, tout progiciel ncessite une personnalisation qui peut aller du plus simple (quelques informations tapes sur lcran) au plus compliqu (par exemple, dveloppement de fonctionnalits spcifiques). Cette phase peut bien souvent
engendrer des surprises qui se concrtiseront par des dlais et des cots supplmentaires et non
prvus. Ces difficults sont amplifies dans le cas des progiciels daudit et de contrle du fait de la
dpendance vis--vis de lditeur, qui est en gnral le seul pouvoir dvelopper son outil.
Ces difficults sont gnralement prvenues par :
des besoins centrs sur lessentiel ;
la slection du progiciel le plus adapt, limitant ainsi au minimum les efforts de personnalisation ;
une validation au fil de leau de la personnalisation ;
une prise en compte au plus tt des risques, si une personnalisation consquente savre
ncessaire.
IFACI
42
PARTIE 6
S TRATGIES
IFACI
DE TESTS , DE DPLOIEMENT ET DE GESTION DU CHANGEMENT.

P OURQUOI , JUSQU O ?
43
6.1 D VELOPPER LES STRATGIES
DE TESTS ET DE DPLOIEMENT
Nous avons dj voqu les tests et dploiement lors de ltude des besoins (cf. 3 Exprimer les
besoins p. 18). En effet, les tests se conoivent ds lexpression des besoins car ils permettent, ds
cette phase, de vrifier la qualit de celle-ci. On pourrait dire que la conception des tests est une
tape de lexpression des besoins.
La stratgie de test se pose avec dautant plus de force que lanalyse des risques a permis danticiper
une sensibilit importante du service daudit ou du contrle interne, voire de lorganisation, la
bonne mise en uvre du projet.
La phase test
La stratgie de test se dcline en plusieurs thmatiques fonctionnelles cohrentes, elles-mmes
divises en plusieurs tests. Ces diffrentes thmatiques peuvent tre testes indpendamment les
unes des autres.
Le tableau ci-dessous prsente quelques exemples de tests pouvant tre effectus pour un projet :
Thmatique
Action
Rsultats attendus
Validation
Commentaires
Organisation Cration dune entit

Etablissement 1
rattache la filiale
A .
L'tablissement 1 est
correctement cr et
rattach la filiale A
dans larborescence
des entits
organisationnelles.
OK
Organisation Modification du nom

de lentit
Etablissement 1 en
tablissement 2 .
Le nom de lentit est

mis jour et saffiche
correctement.
KO
Organisation Cration dun nouvel

utilisateur affect
une entit et un
processus spcifiques.
Lutilisateur est affect

la bonne entit et au
bon processus.
OK
Scurit
Dconnexion
automatique de la
session utilisateur.
Lutilisateur est
automatiquement
dconnect de sa
session au bout de 3h
dinactivit.
KO
Lutilisateur est
dconnect aprs 30
minutes dinactivit,
patch serveur mettre
jour.
Reporting
Exportation des
Les rapports sous
rapports par processus Excel seffectuent
sous Excel.
conformment aux
spcifications.
OK
Les macros doivent

tre actives pour que
les graphiques soient
gnrs.
IFACI
44
Ainsi, la stratgie de dploiement, c'est--dire les diffrentes tapes de mise en uvre de loutil,
par lotissement fonctionnel, gographique ou autre, doit tre pense en fonction de la stratgie de
tests.
Par ailleurs, il peut tre intressant de dfinir un certain nombre dindicateurs de performance qui
permettront de suivre et mesurer en temps rel la rsolution par lditeur ou par lintgrateur des
carts constats :
nombre de dfaillances rsolues entre deux phases de test,
temps de traitement / rsolution des problmes constats.
Il est important de bien drouler et suivre les plans de tests afin de noublier aucun point important
au moment de la recette de la solution.
La phase pilote
Aprs la phase de test et avant la mise en production, la mise en place et le droulement dune
phase pilote va permettre de tester la majorit, voire la totalit, des fonctions de loutil.
Lintrt de cette tape est de drouler la suite, et non plus sparment lensemble des fonctionnalits de loutil, et dobtenir un retour dexprience de la part des utilisateurs.
La phase pilote va permettre de sassurer que les fonctionnalits de loutil sembotent correctement et que loutil gre les cas particuliers.
Il est important que le primtre fonctionnel et organisationnel de la phase pilote soit suffisamment large pour couvrir les principales fonctionnalits. De mme, dans le cadre dun questionnaire
dauto-valuation du contrle interne, inclure une filiale ltranger peut aider anticiper dventuels problmes techniques (type connexion distance) avant le lancement de la campagne classique. La phase pilote doit faire lobjet dun retour dexprience et, ventuellement, dun
questionnaire de satisfaction de la part des utilisateurs pilotes. Ce retour terrain permettra de
remonter dventuels dysfonctionnements et de procder certains ajustements, qui seront dautant plus pertinents que le panel dutilisateurs pilotes sera choisi parmi des personnes sensibilises
aux activits daudit et de contrle internes.
IFACI
45
6.2 G RER LE
CHANGEMENT
La gestion du changement est ncessaire ds lors que les interfaces hommes / machines (IHM), les
mthodes de travail, les acteurs ou encore les attendus voluent.
Elle se gre de lexpression des besoins jusqu la mise en uvre.
Facteurs cls de succs
Anti patterns
Lvolution rpond une demande des utilisateurs.
Impose
Lvolution facilite le travail des utilisateurs.
Alourdissement des tches
Lvolution enrichit positivement le travail des utilisateurs.
Dpossession
Les utilisateurs sont acteurs de toutes les tapes du projet.
Communication descendante
Pour des primtres homognes et ne concernant pas un nombre lev de personnes, la gestion du
changement est souvent une faon de faire passer la pilule d'objectifs inadquats, d'une
mauvaise conception, de tests insuffisants, d'une organisation inadapte, etc.
La taille des services d'audit ou de contrle internes est gnralement modeste. Permettre aux utilisateurs de s'impliquer toutes les tapes du projet, mme les plus amont, afin d'optimiser la
gestion du changement, ne devrait pas constituer un dfi insurmontable.
Toutes choses gales par ailleurs, mieux un projet est conduit, moins il y a besoin de gestion du
changement en tant que phase spcifique du projet. Plusieurs modalits peuvent tre envisages
passant par une formation de lditeur pour lensemble des utilisateurs, les conseils de lintgrateur
ou la formation de formateurs qui prendront le relais pour accompagner le changement auprs des
utilisateurs finaux.
IFACI
46
PARTIE 7
M AINTENANCE /
IFACI
ADMINISTRATION
47
Il ne faut pas sous-estimer les tches dadministration quimplique le recours des progiciels.
Ce poids nest pas linairement proportionnel la taille du progiciel ou au nombre dutilisateurs :
le ticket dentre peut tre lourd.
Plusieurs axes dadministration peuvent tre dgags :
ladministration des donnes (gestion des accs, mise jour documentaire, paramtrage,
archivage, etc.) ;
le contrle de conformit aux procdures (surveiller par exemple que les donnes soient
saisies en temps opportun, avec les bons formulaires) ;
le contrle de la fiabilit des donnes (cf. annexe 8 La fiabilit des donnes , p. 73) ;
le support aux utilisateurs qui est trop souvent nglig et mal dimensionn dans ce type de
projet de (gestion des incidents, questions, demande de modifications, etc.) ;
la formation des nouveaux arrivants dans le service (qui sen occupe ? quels sont les
messages ? Y a-t-il une possibilit de e-learning notamment pour les organisations dcentralises ?) ;
grer les modifications du progiciel (planifier le changement de version, organiser des tests,
notifier aux utilisateurs lindisponibilit de lapplication, etc.).
Ces points ne doivent pas tre ngligs sous peine de remettre en cause de lutilit du logiciel.
Il ne faut pas sous-estimer le temps consacr aux tches dadministration de donnes (gestion des
accs, mise jour documentaire, paramtrage, archivage, etc.) quimplique le recours des logiciels
intgrs , notamment lorsque lquipe daudit interne est dun effectif infrieur ou gal 10
personnes. Il convient didentifier la ou les personne(s) en charge de ladministration de loutil
(responsable qualit du dpartement si il existe, lassistante du service, une personne ddie, etc.)
et de les former en consquent.
Un outil ne permet pas de sexonrer du travail pralable de comprhension des donnes traiter :
que signifient-elles (quel est leur sens) ? Couvrent-elles nos besoins daudit ? Sont-elles fiables et
utilisables ? (cf. annexe 7 La fiabilit des donnes , p. 71).
IFACI
48
Risque
Rponses
Etapes de test non mises en uvre.
Grer le planning dune manire rigoureuse.

Estimer le planning au regard des risques
grer, y compris quand le projet prend du
retard.
Eviter les mises en uvre catastrophiques et
chaotiques.
Non matrise des cots et des ressources

ncessaires la mise en uvre des tests.
Faire attention au calendrier de lditeur.

Eviter les changements au fil de leau,
privilgier des modifications groupes en lot
pour minimiser le travail de test 1 ou 2
montes de version dans lanne.
Dpendance vis--vis de ladministrateur.
Si possible prvoir un binme. En tout tat de

cause, organiser la supplance.
Mauvaise gestion de la relation avec lditeur.
Sinformer sur le calendrier des versions et les

nouvelles fonctionnalits.
Participer un club dutilisateurs.
Bien formuler ses demandes dvolution.
Evaluer le cot de maintenance des
dveloppements spcifiques et leurs impacts
lors de changement de version, etc.
IFACI
49
PARTIE 8
LE
IFACI
DUR EXERCICE DU MIROIR
SAVOIR FAIRE UN BILAN
50
Un bilan de projet a comme objectif essentiel de nous aider gagner en exprience. Il doit, en
consquence, tre profondment honnte : on ne fait un bilan, ni pour plaire, ni pour rgler ses
comptes.
Le responsable de laudit interne avait-il surestim le besoin ? Il faudra en dcrire la cause
et les consquences.
Le chef du projet a-t-il t capable danimer les ateliers dexpression de besoins ? On crit
pourquoi.
Il faudra systmatiquement se rfrer aux objectifs initiaux du projet (tels que formuls dans le business case) et valuer les carts pour en tirer les consquences en termes de :
ce quil faut refaire ;
ce quil aurait fallu faire ;
ce quil ne faut plus faire, etc.
On pourra utilement reprendre la typologie dexigences labore lors de lexpression des besoins
(cf. annexe 2 Organisation de sessions participatives dexpression des besoins , p. 54) ainsi que
le tableau de bord de suivi des dlais et des cots afin de constituer la trame du bilan.
Si ctait refaire ? Retours dexpriences de responsables daudit et de contrle internes en 5
points cls.
1. Avoir le mme interlocuteur (qualifi et comptent) chez lditeur du dbut la fin du
projet. Veiller ce que les changements ventuels soient justifis et ne se traduisent pas par
une baisse de ractivit.
2. Ne pas faire lconomie dune phase pilote avant les tests en grandeur nature cela apporte
beaucoup mme si le projet prend un peu de retard.
3. Avoir ds le dbut une vision de lusage de loutil 3 ans : par exemple, largir le module
contrle interne au module audit ou linverse. Cela conditionne le projet et les solutions
proposes.
4. En profiter pour renforcer les liens entre laudit, le contrle interne et la gestion des risques.
Partager un outil commun aide beaucoup.
5. Ne pas sous-estimer la formation des utilisateurs.
IFACI
51
A NNEXES
IFACI
ANNEXE
52
A NNEXE 1 - CONSEILS
SI L ON RALISE SOI - MME L OUTIL
Les questions se poser avant dentamer une ralisation sont :

Ai-je les comptences ?
Ai-je estim le travail raliser en faisant usage des meilleurs pratiques ?
Serai-je en capacit dassurer la maintenance et, si besoin, le support utilisateur ?
Risque
Rponses
Perte des connaissances techniques.
Documenter clairement et lisiblement la

solution.
Sassurer que les connaissances ncessaires
lexploitation sont maintenues et accessibles.
Difficult grer les versions

Matriser la dpendance vis--vis dune
comptence rare.
Rester au plus prs dune utilisation standard

de loutil. En effet, dans le cas o ladaptation
de loutil aux besoins ncessiterait des
dveloppements spcifiques trop importants,
cela pourrait entraner des problmes lors des
montes de version de loutil. Mieux vaut
alors rflchir la possibilit de faire voluer
ces processus ou lutilisation dun autre
outil plus adapt.
Rester au plus prs des capacits de loutil
utilis pour le dveloppement.
Changer doutil au bon moment.
Erreur de conception et de ralisation.
Vrification des documents et des codes par

des pairs.
Dfinition de plans de tests dtaills et
sassurer de leur ralisation complte.
IFACI
ANNEXE
Comme dans tous projets informatiques, le service daudit ou contrle interne pourrait prfrer (faire) dvelopper en interne loutil recherch plutt que de lacqurir pour diverses
raisons (personnalisation de la solution, logiciel dj existant au sein dun autre service, cot
limit, etc.). Il peut arriver, par exemple, que suite la phase danalyse des besoins, lacquisition dune solution complte dun diteur ne rponde pas aux attentes exprimes. En effet, si
lobjectif est damliorer la traabilit de linformation, larchivage des donnes et de faciliter
les validations, le dveloppement de bases documentaires au sein dun Lotus Notes dj
prsent dans la socit serait peut tre suffisant.
53
A NNEXE 2 - O RG ANISATI ON
DE SESSI ONS PARTI CI PATI VES D ' E XPRE SSI ON D ES
BESOINS
Cette annexe prsente les lments phares de la mthode RAD (rapid application design) et le
droulement d'un JRP (joint requirements planning) qui vous permettront d'organiser des
sessions participatives d'expression des besoins.
La conduite de runion RAD est fonde sur :

une prparation mticuleuse. L'ordre du jour est prpar la minute prs. Les
exposs illustrant une session sont identifis dans l'agenda avec un dbut et une fin
(en heure et minute), ils sont prpars et prsents l'avance l'animateur de la
session.
L'animateur de session est responsable de la bonne tenue de la runion. Il vrifie
que les chefs de projet ont bien invits les personnes ncessaires la discussion mais
aussi la prise de dcision. En effet, le (ou les) dcideur(s) doit(vent) tre prsent(s)
car il ny a pas de session RAD sans prise de dcision : quels besoins sont inutiles ?
Quels objectifs sont rejeter ou au contraire approfondir ? etc. En RAD, le dcideur
n'est JAMAIS l'animateur de la runion.
Les chefs de projet Utilisateurs et Prestataires informatiques participent la
runion. Ils la prparent sous la direction de l'animateur.
Il y a aussi un rdacteur dsign. Adjoint de l'animateur, c'est lui qui ralise la
synthse au fur et mesure de la runion. Dans son rle, il peut demander des claircissements supplmentaires, afin de clarifier les termes changs. Il fait valider sa
synthse intervalle rgulier (un projecteur est toujours utile). Il s'assure aussi du
respect de l'agenda de la session d'une manire autoritaire.
ANNEXE
RAD est une mthode itrative qui part du principe que les utilisateurs ne connaissent pas
vraiment leurs besoins ds le dbut du projet et que leur participation au projet leur permettra d'affiner celui-ci.
Un JRP consiste mettre en place une suite de runions structures ayant pour but la
production rapide dune expression des besoins valide et fiable.
Rappelons rapidement que la phase de JRP est la deuxime phase de la mthode RAD. Elle
est en effet uniquement prcde par la phase d'initialisation du projet, qui permet de fixer
le cadre du projet et son organisation. Elle est suivie par les phases de conception, puis de
ralisation. Il faut savoir que l'expression des besoins obtenue l'issue du JRP n'est pas fige,
elle est prvue pour voluer le long des phases de conception et de ralisation.
IFACI
54
Il faut souligner que la qualit de l'organisation (rles et responsabilits, tapes, rendus,

dlais, mode de communication, etc.) est essentielle la russite de cette mthode.
Une expression des besoins par JRP prend de une trois journes temps complet. Cette
tche gagnerait tre ralise, de prfrence l'extrieur du lieu de travail habituel, afin que
les personnes concernes ne soient pas dranges par le quotidien.
ANNEXE
Bien sr, il est toujours hasardeux d'utiliser un outil sorti de sa dmarche. Pour un JRP qui ne
s'inscrit pas dans un cycle itratif de dveloppement RAD, on pourrait imaginer de tenir,
selon l'importance du projet, une trois sessions dune ou deux journes afin d'exprimer le
besoin et de mettre en exergue les lments indispensables (les sine qua non) qui permettront
de statuer sur la poursuite de la continuation du projet, et d'valuer sa russite lors du bilan.
IFACI
55
A NNEXE 3 - E TAT
DES LIEUX DES BESOINS
A. Contexte : le projet
B. Objectif(s) et caractristiques gnrales de loutil recherch
B.1. Primtre fonctionnel
B.2. Principaux utilisateurs
B.3. Critres techniques
C. Contexte, risques et contraintes
C.1. Organisation
C.2. Principes de fonctionnement
D. Mthodologie de contrle interne
D.1. Le rfrentiel
D.2. Evaluation des risques
E. Projet de dploiement
E.1. Calendrier et tapes attendues
E.2. Reprise de lexistant
F. Schma organisationnel cible
F.1. Scnario 1
F.2. Scnario 2
F.3. Scnario 3
ANNEXE
1- Exemple de sommaire dun tat des lieux rdig dans le cadre du

service de contrle interne
2- Illustration dans le cadre du dploiement dun outil de contrle interne

Les illustrations donnes entrent dans le sommaire prsent ci-dessous (la numrotation a
t reprise).
A. Contexte : le projet
B. Objectif(s) et caractristiques gnrales de loutil recherch
B.1. Primtre fonctionnel
Loutil recherch doit rpondre dans un premier temps un certain
nombre de fonctions de base :
gestion du rfrentiel de contrle interne ;
IFACI
56
Cet outil doit pouvoir voluer terme, en fonction du niveau dappropriation et dacceptation par les utilisateurs, par lajout des fonctionnalits suivantes :
gestion documentaire de premier niveau Diffusion des bonnes
pratiques ;
module Audit Interne et aide au plan daudit / Cartographie des
risques.
La liste des fonctionnalits dtailles attendues sera dcrite dans un
document spcifications fonctionnelles dtailles .
Lexploitation des donnes doit pouvoir tre ralise facilement par les utilisateurs, indpendamment de loutil slectionn.
Il convient donc de disposer dun module de reporting intgr la solution ou dun
module externe utilisant les donnes tires de la solution (notamment la possibilit dexporter des donnes vers des outils bureautiques classiques).
ANNEXE
diffusion de ce rfrentiel au sein des filiales faisant partie du

projet contrle interne ;
documentation du contrle interne par les oprationnels, avec
prise en compte de lexistant ;
valuation du contrle interne (conception et efficacit des
contrles) laide de tests ;
plan daction et suivi ;
gestion de questionnaires type ou questionnaire sur les processus.
B.2. Principaux utilisateurs

Les principaux utilisateurs de cet outil sont :
Les entits mtiers : chaque entit concerne par le projet utilisera
loutil pour documenter son contrle interne et procder des
valuations.
Les services de laudit et contrle internes : elles doivent pouvoir
sappuyer sur loutil pour diffuser les rgles appliquer, pour
contrler la mise en uvre, effectuer un reporting des risques et
valuer globalement le contrle interne.
Les auditeurs externes, qui pourront, le cas chant, utiliser cet
outil ou les lments de reporting issus de loutil dans le cadre de
leur valuation du contrle interne.
IFACI
57
Le paramtrage, le dploiement, lutilisation et lvolution de loutil

doivent pouvoir tre grs de faon simple, en limitant les ressources
DSI.
Les modalits de paramtrages doivent permettre de faire voluer facilement le contenu et le mode de fonctionnement de loutil. Linterface
utilisateur doit tre ergonomique. La technologie employe doit faciliter le dploiement et la maintenance de loutil, tout en assurant sa
prennit ainsi que la confidentialit des traitements, y compris dans
des environnements Web.
Le dploiement de loutil doit prendre en compte les spcificits du
rseau informatique ( dtailler).
ANNEXE
B.3. Critres techniques

Loutil recherch doit reposer sur une technologie simple mettre en
uvre, sinsrant dans larchitecture et lenvironnement technique
dont les standards sont :
Base de donnes XXX ;
Interface Utilisateur XXX et Serveur dapplication XXX ;
Dploiement dapplication de type Client / Serveur XXX ;
Gnrateur de rapports XXX ;
Autres contraintes techniques dtailler avec la DSI.
C. Contexte, risques et contraintes

Prciser le nombre de filiales, le mode dorganisation (ple, activits, secteur,
etc.).
Parmi les contraintes fortes affectant ce projet, on relvera :
la reprise de lexistant
un niveau de dcentralisation important du projet,
la coexistence de plusieurs rfrentiels de contrle interne.
D. Mthodologie de contrle interne1
D.1. Description du rfrentiel
Nombre de processus, de risques et de contrles.
Objectif du rfrentiel.
Application du rfrentiel
- Rgles de documentation des processus, risques et des
contrles.
1
IFACI
Pour plus de prcisions sur ces approches, vous pouvez vous rfrer dautres publications de lIFACI par exemple Lautovaluation du Contrle Interne ou Des cls pour la mise en uvre et loptimisation du contrle interne .
58
- Guide, mthodologie et exemple de document.

- Phase dvaluation, etc.
E. Projet de dploiement
Nom des phases
Etude
Jalon
Nov.-Dc.
Rdaction des spcifications gnrales et fonctionnelles

Finalisation de la short list
Retour et Analyse des rponses
Choix du produit et signature pour pilote
Janvier
Cration dun environnement pilote

Tests des fonctionnalits
Dfinition des modalits de paramtrage
Scnarios de mise en uvre
Slection et Implication des Activits pilotes
Ralisation pilote sur 2 3 Activits et validation de la cible
Stabilisation de loutil et recette
Fvrier
Mars
Derniers dveloppements, tests et recettes
ANNEXE
Prparation des pilotes
Finalisation du paramtrage
Finalisation / validation du paramtrage par Activits / filiales
Recette finale
Mars
Prparation des formations

Prparation dune base et dun serveur formation
Formation
1 au 15 avril
Formation des relais Activits

Reprise de lexistant
Avril-Mai
Reprise de lhistorique et validation

Campagne dvaluation
Avril-Juin
Consolidation premire campagne
IFACI
59
F. Schma organisationnel cible

Le Groupe comporte quatre activits et plus de 100 entits. Chaque activit
pilote un nombre variable dentits qui peuvent tre regroupes en profils
homognes de processus : entit de production, entits logistiques, entit de
distribution, etc.
Lorganisation type dune activit est la suivante :
Un Directeur Gnral assure la responsabilit ultime du contrle interne,
pour lensemble des entits qui lui sont rattaches.
Il est assist dun contrleur interne en charge de lanimation du contrle
interne.
F.1. Scnario 1 Utilisation de loutil sur lensemble des filiales

Dans ce scnario, toutes les filiales du primtre utilisent directement
loutil de documentation et dvaluation du contrle interne (y
compris lactivit pour les processus qui lui sont propres).
Il convient de dcrire les impacts sur lorganisation, lutilisation de la
solution et le nombre des utilisateurs de la solution en fonction des
scnarios retenus.
ANNEXE
Diffrents scnarios organisationnels sont envisags pour la mise en place et

lutilisation de loutil au sein dune activit. Le choix des scnarios ou leur
dploiement successif sera dfinitivement arrt lors de la phase pilote.
F.2. Scnario 2 Utilisation de loutil au niveau de lactivit et partiellement

au niveau des filiales
Dans ce scnario, une partie des filiales utilisent directement loutil de
documentation et dvaluation du contrle interne, selon lapproche
dfinie dans le scnario 1.
scnarios retenus.
F.3. Scnario 3 Utilisation de loutil au niveau de lactivit uniquement
Dans ce scnario, seule lactivit utilise loutil. Les changes dinformations entre le secteur et les filiales se font par messagerie (rfrentiel, instructions de test, reporting).
scnarios retenus.
IFACI
60
A NNEXE 4 - E XEMPLES
DE GRILLE DE SLECTION
Exemple 1
Commentaires
Notation 1 ( mauvais)
3 (bon )
Rponse : Standard Developt - Non
Elments descriptifs
Elments de la slection
Qualification /
essentiel ou
souhaitable
Rponse logiciel A
Plateforme technologique requise
Spcification des postes utilisateurs serveur central (Matriel et

logiciel)
Existence de contraintes
Qualit du prestataire
Capacit du prestataire prendre en charge la matrise duvre
du projet
Taille en effectif
Base gographique
ANNEXE
Description Plateforme (Matriel et logiciel)
Perspective de dveloppement et situation financire

Nombre de personnes affectes au projet
Lexpertise technique des prestataires et des expriences projet
similaires
Base clients actuelle
Perspective de dveloppement
Club utilisateurs
Plateforme de communication
Solidit financire et prennit
IFACI
61
Solution 3
Navigation - les auditeurs peuvent accder rapidement et aisment aux documents de

travail, aux constats et observations
Base de donnes partage (via internet ? Rseau de lentreprise ?)
Fonctionnalits en mode dconnect (du rseau de lentreprise)
Bonne connexion / rapidit / pas de perte de travail occasionne par des dconnexions
rseau
Fonctionnalit de sauvegarde automatique
Possibilit de copier-coller afin de rutiliser les documents de travail, constats, programmes

d'audit
Aide personnalisable
Suivi des modifications / historique des formulaires
Facilit et suivi des revues et des retours de commentaires des documents de travail (simple /
complexe / problmatique, etc.)
Droits daccs - tous les auditeurs ont-ils accs aux audits ?
Droits daccs - est-il possible de limiter les droits certaines sections ou certains projets ?
Dispose d'une technologie de retour arrire
PREMIER CHOIX DANS CE DOMAINE
Lgende
Moins bon rsultat de sa catgorie =

Meilleur rsultat de sa catgorie =
!
= Dsign comme une exigence minimale par l'quipe charge du projet
Solution 1
Solution 2
Exemple 2
N
O
ANNEXE
FONCTIONNALIT DE BASE
PERSONNALISATION
Modification des noms des champs (quelques-uns / plusieurs / tous)
Ajout de nouveaux champs (limit / partout)
Modification de la typologie des champs commentaire / date / menu droulant /

radio (quelques-uns / plusieurs / tous)
Laffichage des champs est-il personnalisable ?

Des points dtape / de validation peuvent tre enregistrs et suivis (facile / complexe)
Des domaines fonctionnels peuvent tre automatiquement relis un contrle et valus
(facile / complexe)
Possibilit de choisir manuellement un domaine fonctionnel quand ncessaire (facile /
complexe)
IFACI
O
O
62
Solution 1
Solution 2
Solution 3
Stockage de la documentation lectronique / accs la documentation d'audit

archive
Fonctionnalits avances de recherche
Recherche des preuves daudit
Les fichiers peuvent tre dplacs et copis (facile / complexe)
Historique / sauvegarde automatique des projets de documents
Une liste de preuves daudit peut tre gnre dans un rapport
Lgende
DOSSIERS JUSTIFICATIFS
Recherche directement dans les champs

Recherche dans les documents
Les documents de tailles importantes peuvent tre imports
!
Importation / exportation de plusieurs documents

Les noms des fichiers peuvent tre modifis dans le logiciel
O
O
TEST DES CONTROLES

Des processus entiers peuvent tre imports (facilement / difficilement)
Des contrles individuels peuvent tre imports (facilement / difficilement)
Des contrles gnriques peuvent tre crs (facilement / difficilement)
Formulaire / champs pour tester les contrles (champs requis : apprciation globale du
contrle, domaine fonctionnel)
Il existe une solution permettant de tester les contrles sur diffrents sites (facile / compliqu)
Importation automatise des processus / contrles / procdures de test dans la page

de test du contrle
Importation automatise des processus / contrles / procdures de test dans le logiciel

(paramtrage administrateur)
Importation automatise des modles de test et autres preuves
Les contrles peuvent tre valus depuis un seul cran
Les tests des contrles, constats et plans d'action sont regroups sur un formulaire (rpond
nos besoins, c'est--dire plusieurs sites et dates de constats)
Des contrles multiples peuvent tre imports (facilement / difficilement)

Ajout / suppression / modification des contrles en mode dconnect
!
IFACI
ANNEXE
63
Solution 1
Solution 2
Solution 3
Formulaires / champs pour enregistrer les constats (peuvent-ils tre rapprochs de nos
champs obligatoires ?)
Traabilit automatique du suivi du plan d'action (fonctionnalit de suivi des dficiences)
Lgende
CONSTATS ET PLANS D'ACTION

!
Les constats peuvent tre directement transmis au management partir du logiciel (pas de
cot supplmentaire / cots supplmentaires)
Les rponses du management peuvent tre ajoutes directement / automatiquement dans le

logiciel (pas de cot supplmentaire / cots supplmentaires)
Les commentaires relatifs aux plans d'actions peuvent tre intgrs aux constats
IFACI
Tous les champs peuvent tre transfrs dans un tableur
Tous les champs peuvent tre filtrs et tris (y compris les champs modifis / ajouts)
Reporting de la synthse daudit (rsultats des tests, domaines fonctionnels, etc.)
Actualisation des champs depuis un cran de consolidation
Les champs peuvent tre exports dans un rapport d'audit gnr automatiquement (en
nombre limit / certains / la plupart / tous)
Gnration des rapports hypertexte pour accder directement aux documents
Gnration de rapports au format Word
Gnration de rapports au format PDF
Gnration de rapports au format Excel
Outils pour raliser des graphiques
Les modifications des rapports d'audit (dans un fichier externe) peuvent tre rintgres
dans la base de donnes
Alertes lectroniques (e-mail) pour les utilisateurs
Alertes lectroniques (e-mail) pour les non-utilisateurs
Les rapports peuvent tre personnaliss par l'utilisateur
Les modles de rapports peuvent tre personnaliss (filtres, conditions, formules) et rutiliss
avec des donnes actualises
Les rapports peuvent tre excuts automatiquement dans le cadre d'une planification et
visualiss par tous
PREMIER CHOIX POUR LE REPORTING PONCTUEL / L'LABORATION DE

GRAPHIQUES
ANNEXE
REPORTING
64
Solution 1
Solution 2
Solution 3
Tlchargement de l'intgralit des donnes d'audit, y compris les preuves daudit (facile /
complexe)
Existence des fonctionnalits de gestion des risques / valuation des risques / univers des
risques au sein du module
Outils de planification
Les fonctionnalits couvrant la gouvernance, les risques et la conformit sont-elles incluses

dans le prix du progiciel ?
Lgende
Proximit / disponibilit des gestionnaires de compte / du support ( proximit, 24h sur 24,
7 jours sur 7)
Combien de mois la mise en uvre dure-t-elle en moyenne ?
Quelle est la frquence annuelle des mises jour ?
Possibilit de mode SAAS / Cloud
Cot des logiciels / licences

Cots de maintenance
Cots de formation
Autres cots
IFACI
Importation automatique de donnes depuis d'autres outils (e.g. SAP, etc.)
ANNEXE
AUTRE
65
Exemple 3
SPECIFICITES
Couvrir 50 filiales avec environ 850 utilisateurs
Permettre de relier des processus des risques
Permettre de relier des risques des contrles
Mettre en place un processus de dlgation et de supervision dans la documentation
des contrles et dans les tests
Un reporting en ligne simple et rapide avec des indicateurs cls
Possibilit de crer des rapports varis sans passer par lditeur avec des axes danalyses varis (BU, BD, Zone, Rgion, Pays, Filiale)
Un suivi des plans daction
Utilisation facile pour les auditeurs, contrleurs internes, responsables oprationnels
Bonne rputation du vendeur
Une hot line disponible 24/24, 7/7 mme depuis ltranger
Editeurs / Critres
Lier des processus des risques (Majeur)
Lier des risques des contrles (Majeur)

Cration rapide dutilisateurs
Processus de dlgation et de supervision dans la documentation et dans les tests
Reporting intgr en ligne simple et rapide avec des indicateurs cls (Majeur)
Possibilit de crer des rapports varis sans passer par lditeur avec des axes danalyses
Suivi des plans daction (Majeur)
Utilisation facile (Majeur)
Bonne rputation du vendeur
Une hot line disponible 24/24, 7/7 mme depuis ltranger (Majeur)
IFACI
ANNEXE
BENEFICES ATTENDUS
Etre en capacit de soutenir le processus Sarbanes-Oxley dans lorganisation
Documenter les objectifs de contrles ainsi que les procdures de contrles (narratives, diagramme de circulation, vidence du contrle)
Permettre un suivi de lavancement de la documentation de lexistence des contrles
Evaluer lefficacit des contrles existants par une auto-valuation et des tests indpendants
Consolider les rsultats sur les tests (% davancement de la documentation, % de
contrles tests / non tests, fonctionnant / ne fonctionnant pas, etc.)
Mise en place et suivi de plans daction
66
Exemple 4
Solution 1
Solution 2
Solution 3
CRITRES
Scurit des accs
Cut-off (en deux annes)
Documentation des modifications + versionning
Vitesse pour gnrer des rapports
Utilisation facile
Multi-critres
Existence dalertes
Peu de formation exige
Ergonomie
Menu Aide et support tlphonique
Suivi des plans daction
Multilingue (Franais Espagnol)
OPTIONNEL
Cartographie des risques
Suivi des plannings
Indicateurs de performance
IFACI
ANNEXE
Standard technology (java, intranet, database)
67
A NNEXE 5 - L ANALYSE
DES DONNES
Selon le GTAG sur les technologies danalyse de donnes1, lutilisation des technologies
danalyse de donnes est de nos jours un atout majeur qui permet aux auditeurs daccrotre
la couverture de leurs audits, dtre plus efficace et davoir un degr dassurance plus important.
Dune manire gnrale, lutilisation dindicateurs cls issus danalyses de donnes permet
dvaluer et dapprcier au mieux les risques lis aux processus oprationnels et financiers.
De plus, un grand nombre de revues analytiques et danalyses telles que les analyses lies
la loi de Benford2, les dtections de doublons, les ruptures de squences, permettent de
dtecter trs rapidement des anomalies et ainsi dorienter ses recherches. Par exemple, de
telles analyses permettent de quantifier de manire prcise limpact dun contrle dfectueux
ou dune fraude avre ou suppose. Lannexe A de ce GTAG propose une liste de requtes
ralisables titre dillustration dans le cadre dun audit sur le processus achats.
Cependant, il est important de souligner que laccs aux donnes ainsi que llaboration
danalyses et de rapport dexception peuvent tre compliqus et fastidieux, en labsence de
solution adapte et du niveau de comptence ncessaire pour comprendre et faire fonctionner de tels outils. En effet, il est ncessaire :
de localiser et daccder aux donnes dont les sources peuvent avoir diffrents
formats (comprhension de la structure des donnes dune base),
de ne conserver que les donnes utiles et pertinentes.
ANNEXE
Bien que les services daudit interne effectuent de lanalyse de donnes depuis plus de 25 ans,
cest seulement depuis quelques annes que cette dmarche sest standardise. Lanalyse de
donnes permet aux auditeurs davoir une vision globale relative la gestion des processus
oprationnels ainsi que financiers, et permet rapidement daller un niveau de dtail mais
aussi de cibler ses recherches.
A titre dexemple, les diteurs les plus connus de lanalyse des donnes pour les auditeurs
comme pour les contrleurs sont ACL et IDEA. Mais dautres solutions trs rpandues
comme Microsoft Access ou simplement Excel peuvent, dans une moindre mesure, permettre
de raliser de telles analyses.
Ce GTAG contient galement une grille indicative de critres de slection en annexe B.
1
2
Global technology audit guide : data analysis technologies / Altus J. Lambrechts, et al. IIA, 2011.
La loi de Benford, aussi appele loi des nombres anormaux , est une loi statistique permettant didentifier des anomalies dans une
liste de donnes et chiffres. La loi nonce que le 1er chiffre non nul le plus frquent est 1, le 2 est lui-mme plus frquent que 3, le 3
que le 4 et la probabilit d'avoir un 9 comme premier chiffre est la plus basse. Dans le cadre de lanalyse des oprations diverses
comptable, si lauditeur dtecte une quantit de doprations commenant par 7 anormalement leve, il fera un focus particulier dans
le cadre de son chantillon.
IFACI
68
A NNEXE 6 - O UTILS D AUDIT
ET DE CONTRLE EN CONTINU
Le contrle continu est un mcanisme automatis permettant au management de sassurer

que les systmes et les contrles fonctionnent conformment aux dispositions tablies lors
de leur conception et que le traitement des oprations est rgulier. Les donnes issues du
contrle continu peuvent tre exploites, afin danalyser les performances ou didentifier des
transactions suspectes qui pourraient rvler des faiblesses de contrle. Ces informations
peuvent galement servir de support la mise en place de contrles ou la ralisation de tests
oprationnels.
Face des dispositifs de contrles permanents de lorganisation de plus en plus automatiss,
systmatiques et frquents grce au contrle continu, l'audit interne doit se positionner lui
aussi comme un dispositif toujours plus en cohrence avec le systme dinformation de lorganisation. Cette mise en cohrence doit tre dynamique pour tenir compte de lvolution
des systmes.
ANNEXE
L'audit continu (CA pour Continuous Auditing) et le contrle continu (CM pour Continuous
Monitoring), bien que leur dfinition varie dune organisation lautre, ont pour objectif doffrir une meilleure transparence des oprations et dassurer la rgularit de la production du
reporting, et ce au plus prs du temps des activits oprationnelles, grce des outils de
dtection et de pilotage.
Il faut souligner que laudit en continu / contrle continu est totalement dpendant de la
qualit et de la pertinence des donnes vhicules par le systme dinformation de lorganisation.
L'audit continu se compose alors essentiellement de deux volets1 :
1. l'valuation continue du contrle, qui se focalise sur la dtection au plus tt des dficiences de contrle ;
2. l'valuation continue des risques, qui met en lumire les processus ou les systmes
qui prsentent un niveau de risque mal apprhend par le systme de contrle
permanent.
Voir le GTAG : Audit continu : Rpercussions sur lassurance, le pilotage et lvaluation des risques / David Coderre, et al., IFACI
trad. IIA, 2005.
IFACI
69
Comme pour l'audit classique, les efforts dploys sur l'audit continu sont fonction du risque
d'audit sur le process ou le systme. De mme, ils sont inversement proportionnels la qualit
des contrles permanents exercs.
D'une faon plus concrte, l'audit continu consiste assurer la collecte automatise, rgulire
ou continue, de preuves daudit et d'indicateurs. Cette collecte est ralise par un contrleur
interne ou un auditeur interne ou externe sur la base des systmes dinformations, des
processus et des contrles dploys dans lorganisation. Les informations recueillies amliorent les capacits daudit et favorisent le respect de la conformit avec les bonnes pratiques,
les procdures et les rglementations. Elles permettent aussi une meilleure prparation des
missions daudit en permettant une analyse des risques plus prcises fonde sur des critres
quantifis. Dans certains cas, laudit en continu doit permettre lidentification des faiblesses
de contrle dans des dlais plus restreints que dans le cadre dune approche classique.
Les organisations qui mettent en place des processus daudit en continu / contrle continu
obtiennent ainsi des avantages considrables :
accrotre les capacits de surveillance des risques et des contrles laide doutils de
pilotage et didentification anticipe des risques ;
prvenir et dtecter la fraude ;
optimiser la ralisation de tests defficacit des contrles et des oprations grce
lautomatisation ;
communiquer (rapidement) des indicateurs dactivit pertinents au comit de direction.
IFACI
ANNEXE
Par ailleurs, le GTAG sur laudit en continu rappelle qu'en l'absence de contrles permanents
adquats, l'audit interne doit raliser des tests approfondis de corroboration, la plupart du
temps sous forme de dispositifs informatiss. Les programmes ou les requtes informatiques
raliss dans ce cadre peuvent alors tre livrs aux entits audites l'issue de la mission
pour enrichir les dispositifs de contrle permanent.
70
A NNEXE 7 - L A
FIABILIT DES DONNES
Nous traitons ici de la fiabilit des donnes dans le cadre de leur exploitation par un outil
danalyse, que ce soit pour un test daudit ou un dispositif daudit en continu / contrle
continu.
Sur ce sujet, les normes daudit du GAO1 sont particulirement clairantes. Elles stipulent
que quand les donnes informatises constituent une part importante ou intgrale du matriel
daudit et que la fiabilit des donnes est cruciale pour raliser les objectifs daudit, les auditeurs
doivent sassurer que les donnes sont pertinentes et fiables. Cette assurance doit tre acquise, que les
donnes soient fournies aux auditeurs ou que les auditeurs les obtiennent par leurs propres moyens.
Pour dterminer le niveau de fiabilit des donnes, les auditeurs peuvent :
soit conduire une revue des contrles gnraux et dapplication des systmes informatiss, en
y effectuant des tests ;
soit conduire dautres tests et procdures, si les contrles gnraux et dapplications ne sont
pas passs en revue ou sont considrs comme non fiables.
ANNEXE
Lanalyse des donnes (et donc les conclusions que lon peut en tirer) est compltement
tributaire de la qualit des donnes brutes utilises. Cela ncessite donc que lauditeur /
contrleur interne se soit assur pralablement de cette qualit, par exemple lors de la
mission / activit en cours, ou en rfrence des audits antrieurs qui lont tabli.
Quand lobjectif principal de laudit est la fiabilit dun systme informatis, les auditeurs devraient
systmatiquement conduire une revue des contrles gnraux et dapplications de ce systme.
Quand les donnes informatises sont utilises (ou cites dans le rapport) par lauditeur titre dinformation et nont pas dimpact sensible sur les rsultats daudit, on considre quil suffit de citer la
source des donnes dans le rapport afin de satisfaire aux normes pour ce qui est de lexactitude et de
lexhaustivit.
United States General Accounting Office GAOs government auditing standards.
IFACI
71
Le GAO propose une dmarche structure1 permettant de sassurer de la qualit des

donnes, en pralable aux tests daudit qui est rsume dans le schma suivant :
Objectifs daudit
Tests daudit
sur des donnes
informatises ?
NON
B
Exercer les tests prvus
Niveau de fiabilit
connu et suffisant ?
NON
Autres sources
de donne
envisageables ?
NON
Apprcier les contrles sur les donnes

Evaluer leffort des travaux pour sassurer de la fiabilit
NON
Effort des travaux

important ?
ANNEXE
Etudier la faisabilit de changer de test daudit ou de

modifier le test afin de ne pas utiliser les donnes prvues
NON
Changement possible ?
Raliser les travaux ncessaires pour apprcier la fiabilit,

lexhaustivit et lauthenticit des donnes qui seront
utilises pour le test daudit
A
Qualit des donnes

suffisante pour exercer
les tests daudit ?
NON
Constats sur la qualit

des donnes
B
Schma global de la dmarche GAO
Pour une introduction cette problmatique, voir Facing the data integrity challenge / Raymond Wessmiller. - in www.itaudit.org
volume 5 May 1 2002. Pour approfondir la dmarche du GAO relative la fiabilit des donnes, voir Assessing the reliability of
computer-processed data: applied research and methods, October 2002, GAO-03-273G.
IFACI
72
RCAPITULATIF DES RISQUES POUVANT ENTRANER L CHEC
DU PROJET
/ R PONSES
Risques
Rponses
Echec du projet (sur les dlais, le budget et la

satisfaction des besoins).
Suivre une dmarche partage.

Raliser un planning raliste.
Raliser des points davancement rguliers
avec des jalons prdfinis (cf. 2.2
Apprcier les risques la mesure des
bnfices attendus lencart sur la notion
de jalon , p. 16).
Mconnaissance de lorganisation.
valuer les connaissances sectorielles du

prestataire. Le donneur dordre doit sassurer
que le prestataire dispose dune bonne
connaissance des exigences sectorielles, de
lorganisation et des organisations similaires.
Mconnaissance des besoins.
Expliciter les objectifs et les rsultats attendus.

Le donneur dordre doit tre clair sur ses
objectifs et les rsultats quil attend de la
mission confie au prestataire.
valuer la bonne comprhension par le
prestataire, des besoins, des enjeux et des
spcificits du mtier dauditeur interne et/ou
de contrleur interne.
Manque dindpendance du prestataire.
valuer les liens conomiques du prestataire

vis--vis des diffrents diteurs du march.
Identifier dautres critres permettant de
supporter limpartialit du prestataire.
Manque de connaissances de loutil.
valuer lexprience de lintgrateur au regard

de la solution choisie.
Obtenir auprs de lditeur et/ou de
lintgrateur une liste de rfrences.
Sassurer que la prestation de service ne soit
pas ralise uniquement par des juniors ,
et quelle comporte un niveau suffisant
dimplication des experts ou managers.
IFACI
ANNEXE
A NNEXE 8 - TABLEAU
73
Risques
Rponses
Sur-adaptation du progiciel.
Privilgier au maximum le paramtrage au

dveloppement spcifique, afin de permettre
une monte de version aise.
Ne jamais toucher au noyau du progiciel
(ligne rouge ne pas franchir et dterminer
avec l'diteur) au risque dentraner le
dsengagement de l'diteur.
Besoins non clairement exprims.
Rdiger un business case.
Cot sous-valu.
Prendre en compte le cot total :

projet informatique
+ licences
+ infrastructure
+ formation initiale
+ formation spcifique administrateur
+ migration de donnes
+ prestataire interne informatique
+ temps des ressources internes
Manque de prcision dans la formulation des

besoins.
Passer par des maquettes et des prototypes.

Dialoguer avec des services dautres
organisations ayant rencontr une
problmatique similaire, par exemple par
lentremise dassociations professionnelles.
Indiffrence, voire rejet des utilisateurs, par

rapport la solution propose.
Faire des sessions participatives dexpression

des besoins et de conception.
Expliciter la plus-value attendue pour les
utilisateurs.
Insister sur lergonomie de la solution (design,
simplicit dutilisation) afin de faciliter son
appropriation par les utilisateurs.
Rexaminer et reprciser l'opportunit du
projet.
Plan de test non appropri.
Elaborer des plans de test pour dtecter des

erreurs, pas pour prouver que a marche.
Anticiper les dlais ncessaires pour corriger
les anomalies dtectes lors des tests.
Plan de test trop linaire.
Construire un plan de test logique et

imaginatif.
IFACI
ANNEXE
Manque de validation par les bons acteurs, au Implication du comit de pilotage.

bon niveau.
74
Rponses
Etapes de test non mises en uvre.
Grer le planning dune manire rigoureuse.

Estimer le planning au regard des risques
grer, y compris quand le projet prend du
retard.
Eviter les mises en uvre catastrophiques et
chaotiques.
Non matrise des cots et des ressources

ncessaires la mise en uvre des tests.
Faire attention au calendrier de lditeur.

Eviter les changements au fil de leau,
privilgier des modifications groupes en lot
pour minimiser le travail de test 1 ou 2
montes de version dans lanne.
Dpendance vis--vis de ladministrateur.
Si possible prvoir un binme. En tout tat de

cause, organiser la supplance.
Mauvaise gestion de la relation avec lditeur.
Sinformer sur le calendrier des versions et les

nouvelles fonctionnalits.
Participer un club dutilisateurs.
Bien formuler ses demandes dvolution.
Evaluer le cot de maintenance des
dveloppements spcifiques et leurs impacts
lors de changement de version, etc.
Perte des connaissances techniques.
Documenter clairement et lisiblement la

solution.
Sassurer que les connaissances ncessaires
lexploitation sont maintenues et accessibles.
Difficult grer les versions.

Matriser la dpendance vis--vis dune
comptence rare.
Rester au plus prs dune utilisation standard

de loutil. En effet, dans le cas o ladaptation
de loutil aux besoins ncessiterait des
dveloppements spcifiques trop importants,
cela pourrait entraner des problmes lors des
montes de version de loutil. Mieux vaut
alors rflchir la possibilit de faire voluer
ces processus ou lutilisation dun autre
outil plus adapt.
Rester au plus prs des capacits de loutil
utilis pour le dveloppement.
Changer doutil au bon moment.
Erreur de conception et de ralisation.
Vrification des documents et des codes par

des pairs.
Dfinition de plans de tests dtaills et
sassurer de leur ralisation complte.
IFACI
ANNEXE
Risques
75
BIBLIOGRAPHIE
Lgislation
Sarbanes-Oxley Act of 2002 (http://www.sec.gov)
Rfrentiels / Normes
ISO/IEC 15504 Information technology - Process assessment (SPICE (Software Process
Improvement and Capability Determination))
ISO/IEC 9126-1:2001 Gnie du logiciel - Qualit des produits
Cadre de rfrence international des pratiques professionnelles de laudit interne / IIA, IFACI trad.
IFACI, 2012.
MPA 2320-2 : Analyse causale.
GTAG 3 Audit continu : rpercussions sur lassurance, le pilotage et lvaluation des risques
/ David Coderre, John G. Verver, J. Donald Warren Jr., IFACI trad. IIA, IFACI ; 2005.
GTAG 16 Government Auditing Standards (2011 Revision) / Comptroller General of the
United States. 2011 (Revised on January 20, 2012).
IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control
Professionals / ISACA. - 2010
IT Audit and Assurance Guidelines: G3 Use of Computer Assisted Audit Techniques (CAATs) /
ISACA. ISACA, 2008.
Ouvrages
Panorama des systmes dinformation de gestion des risques 2012, 4me dition (Cahier technique).
/ AMRAE. AMRAE, 2012
Magic Quadrant for Enterprise Governance, Risk and Compliance Platforms / French Caldwell, John
A. Wheeler. Gartner, 2012.
Gouvernance du systme dinformation : guide daudit / AFAI, IFACI, CIGREF. IFACI, 2011.
Des cls pour la mise en uvre et loptimisation du contrle interne / Unit de Recherche IFACI,
2011
The Forrester Wave: Enterprise Governance, Risk, And Compliance Platforms, Q4 2011 / Chris
McClean. Forrester, 2011.
Vecteur 6 : Matrise de la ralisation des projets en fonction des enjeux mtiers in Le contrle
interne du systme dinformation des organisations / IFACI, CIGREF. IFACI, 2009.
Human Factors in Project Management: Concepts, Tools and Techniques for Inspiring Teamwork
and Motivation / Zachary Wong. ISACA, 2007.
Lauto-valuation du contrle interne (Cahier de la recherche) / Unit de Recherche. - IFACI, 2005
IFACI
76
Enqutes
CBOK - Common Body of Knowledge : vos pratiques au regard des tendances europennes et
mondiales / IFACI. IFACI, 2011.
Imperatives for Change: The IIAs Global Internal Audit Survey in Action (The IIAs Global Internal
Audit Survey: A Component of the CBOK Study) / Richard J. Anderson, J. Christopher Svare. IIA,
2011.
Core competencies for todays internal auditor: report II: the IIAs global internal audit survey: a
component of the CBOK study / James A. Bailey. IIA; 2010.
Articles
Etat des lieux des outils informatiques disposition des auditeurs [dossier]. - revue Audit & Contrle
internes, n212, dcembre 2012.
IT project management / Shannon Buckley. Internal auditor, august 2011.
Leveraging data analysis software / Norman Marks. Internal auditor, august 2009.
Continuous auditing from a practical perspective / Kevin Handscombe. in Information Systems
Control Journal, volume 2, 2007.
An array of technology tools / Glen L. Gray. - Internal auditor, august 2006.
Generalized Audit Software: Effective and Efficient Tool for Todays IT Audits / Tommie Singleton.
in JournalOnline, 2006.
Continuous auditing through leveraging technology / Srinivas Sarva. in Information Systems
Control Journal, volume 2, 2006.
The wave of the future / Douglas E. Ziegenfuss. in Internal Auditor, April 2006.
Why Companies Are Not Implementing Audit, Antifraud and Assurance Software and How to
Fix It / Dean Brooks,Rich Lanza. in JournalOnline, 2006.
A continuous view of accounts / David Coderre. in Internal Auditor, April 2006.
Opening the door / Neil Baker. - Internal auditor, august 2005.
Ralisation :
Ebzone Communication (www.ebzone.fr)
Open source tools for security and control assessment / K.K. Mookhey in Information Systems
Control Journal volume 1, 2004.
Get the most out of audit tools / Russell A. Jackon. in Internal auditor, august 2004.
Continuous auditing: risks, challenges and opportunities / Sean Chen. in The international journal
of management and technology, Volume 1, Number 1, 2003.
Choosing the right tool / Tim McCollum, David Salierno. in Internal Auditor, August 2003.
Data analysis with SQL / Tim McCollum www.itaudit.org, volume 5, September 1, 2002.
IFACI
77

CDR Outil Informatique

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CDR Outil Informatique

Enviado por

Direitos autorais:

Formatos disponíveis

Cahier de la

Slectionner un outil informatique

LIFACI est affili

LIFACI remercie galement pour leur participation la relecture :

La rvision a t assure par :

Philippe MOCQUARD, Dlgu Gnral, IFACI

Une dmarche structure ............................................................................................................................ 12

Exprimer les besoins .................................................................................................................................... 18

La dmarche de slection ............................................................................................................................ 27

Maquetter / dvelopper / paramtrer ...................................................................................................... 42

Stratgies de tests, de dploiement et de gestion du changement. Pourquoi, jusquo ? ............. 43

Maintenance / administration .................................................................................................................... 47

Le dur exercice du miroir : savoir faire un bilan .................................................................................... 50

10. Bibliographie .................................................................................................................................................. 76

Les services daudit ou de contrle internes se trouvent inluctablement confronts la ncessit

De la ncessit de recourir des solutions informatiques

France Europe Monde France Europe Monde

Documents de travail lectroniques

Techniques daudit assistes par

Application de cartographie des

PRENANT EN COMPTE LES RISQUES

RLES DANS LA GESTION DE PROJET

AVO IR RECO URS UN PRE STATAI RE EXTE RNE

valuer les connaissances sectorielles du

Mconnaissance des besoins.

Expliciter les objectifs et les rsultats attendus.

Manque dindpendance du prestataire.

valuer les liens conomiques du prestataire

1.3.1 Lassistance lexpression du besoin ainsi qu la slection du logiciel

Les attentes vis--vis dune quipe de consultants seront alors :

1.3.2 Ladaptation et le dploiement dun progiciel

Manque de connaissances de loutil.

valuer lexprience de lintgrateur au regard

Privilgier au maximum le paramtrage au

La dmarche que nous proposons est illustre par le schma ci-dessous.

Tenir compte de lenvironnement

Concevoir les tests

Evaluer les logiciels

Dmarche de mise en place dun outil

Mettre en place un outil passe par les tapes suivantes :

LES ACTIVITS , LES OBJECTIFS ET LES PRIORITS

Pour la prise en compte de lenvironnement, il est recommand de travailler avec la direction de

Exemples dlments de contexte prendre en compte :

Besoins non clairement exprims.

Rdiger un business case.

Manque de validation par les bons acteurs, au

Implication du comit de pilotage.

Prendre en compte le cot total =

2.2 A PPRCIER LES RISQUES

LA MESURE DES BNFICES ATTENDUS

3.1 PARTIR DES

BESOINS POUR ORIENTER LES CHOIX

Manque de prcision dans la formulation des

Passer par des maquettes et des prototypes.

Indiffrence, voire rejet des utilisateurs, par

Faire des sessions participatives dexpression

Pourquoi un logiciel intgr facilite-t-il la supervision des activits au sein du service ?

Continuer exprimer les besoins

Besoins et tests de rception sont lis ds lamont

Plan de test non appropri.

Elaborer des plans de test pour dtecter des

Plan de test trop linaire.

Construire un plan de test logique et