Guide Audit Applications PDF

Guide daudit des applications
informatiques
Une approche inspire des audits financiers
Novembre 2008
tier
s m
essu
Proc
ions
licat
App
s IT
me
Syst
re IT
uctu
astr
Infr

ITA
CS
Tr
ai
ni
ng
Auteurs: Peter R. Bitterli Jrg Brun Thomas Bucher Brigitte Christ Bernhard Hamberger Michel Huissoud
Daniel Kng Andreas Toggwyler Daniel Wyniger Georges Berweiler (revue de la traduction franaise)
G U I D E D A U D I T D E S A P P L I C AT I O N S I N F O R M AT I Q U E S
Guide daudit des

applications informatiques
Novembre 2008
1
Cet ouvrage est le fruit des rflexions et des expriences des membres de la Commission informatique de la Chambre fidu-
ciaire suisse. Travaillant dans les principaux cabinets daudit comptables et financiers suisses ou dans dimportants services
daudit interne, ceux-ci ont voulu saisir, structurer et standardiser lapproche qui est la leur dans le cadre de laudit des
comptes annuels.Ce document a vocation servir de passerelle entre les auditeurs financiers et les auditeurs informatiques
et devrait renforcer lindispensable cohrence entre les travaux de ces deux disciplines. Ce texte reflte lexprience et la
rflexion de ses auteurs. Il est publi avec laimable autorisation de la commission informatique de la Chambre fiduciaire
suisse. Copyright ISACA Switzerland Chapter, 2008.
Auteurs:
Peter R. Bitterli
Jrg Brun
Thomas Bucher
Brigitte Christ
Bernhard Hamberger
Michel Huissoud
Daniel Kng
Andreas Toggwyler
Daniel Wyniger
Georges Berweiler (revue de la traduction franaise)
Graphiques et mise en page: Felice Lutz, ITACS Training AG
2
Table des matires
Table des matires 3
Prsentation gnrale et introduction 4
Analyse du bilan et du compte de rsultats 7
Identification des processus mtier et des flux de traitement des donnes 9
Identification des applications de base et des principales interfaces IT pertinentes 13
Identification des risques et des contrles cls 18
Tests de cheminement 22
Evaluation de la conception des contrles 24
Evaluation du fonctionnement des contrles 28
Apprciation globale 32
Annexe 1 - Contrles lis aux applications 36
Annexe 2 - Glossaire 38
3
Prsentation gnrale et introduction
But de lapproche Dans le cadre des procdures daudit orientes processus et bases sur lutilisation
dapplications informatiques, il est essentiel de prendre en compte tous les do-
maines importants, y compris les des domaines IT spcifiques ayant une influence
significative sur lobjectif de contrle de lauditeur. Pour y parvenir une approche
de contrle intgre (auditeur et auditeur informatique) est ncessaire. Labsence
de procdure concerte entre auditeurs et auditeurs informatiques (auditeurs IT)
constitue cet gard un risque lev. .
Le prsent document dcrit, dans le cadre des procdures daudit orientes pro-
cessus, une mthode de vrification et une approche intgre de laudit des con-
trles applicatifs destines prvenir ce risque daudit.
Etendue et dlimitation La mthode prsente se limite la procdure de contrle des applications IT au

sein dun processus mtiers. Les domaines connexes sont abords dans la mesure
o ils ont un lien avec la procdure de contrle, mais ils ne seront pas traits en
dtail. Il sagit par exemple des contrles par chantillonnage, des qualifications
des auditeurs et des contrles IT gnraux (vrifications indpendantes dune
application).
Lutilisation de lapproche nest pas limite laudit des critres rglementaires; la

procdure a t conue sciemment de manire plus gnrique afin de convenir
galement dautres vrifications (par ex. vrifications de conformit).
Utilisateurs Les exemples et la description de la procdure se rfrent laudit des tats fi-
nanciers. Compte tenu de son caractre gnrique, lapproche de contrle est
utilisable aussi bien par lauditeur financier que par lauditeur IT.
Laudit des tats financiers dune entreprise reprsente pour les auditeurs financiers un nombre de dfis de plus en plus
grand; dun ct lvolution rapide des normes comptables, de lautre lautomatisation croissante de la prparation des
tats financiers au moyen de systmes dinformation toujours plus complexes. Ce deuxime aspect est le sujet qui est d-
velopp ci-aprs.
La qualit des informations financires dpend dans une large mesure de la qualit des processus mtiers et des flux de
traitement des donnes sy rapportant. Il est donc logique que lauditeur concentre son travail sur ces processus mtiers et
intgre le contrle des applications correspondantes dans son approche daudit.
Lapproche prsente ci-aprs est destine aider lauditeur financier dvelopper une approche daudit intgre et
recentrer la procdure daudit de manire plus efficace et plus cible sur les risques, en intgrant laudit des processus
mtiers pertinents et des applications correspondantes. Lapproche commence donc avec lanalyse des tats financiers de
lentreprise et se termine par lapprciation de limpact des rsultats daudit sur ces tats financiers.
4
Les 8 tapes de la mthode de vrification:

Il est judicieux danalyser les tats financiers afin dorienter
les procdures daudit des processus de lentreprise et des
om pte applications correspondantes sur les tests des comptes fi-
et du c
bilan s nanciers significatifs et sur les risques daudit sy rapportant.
l y s e du rsultat
Ana de
Cette analyse lie les principales positions comptables aux
1 els
ionn
rat processus mtiers pertinents ou, plus concrtement, dter-
s op
ro c essu es
es p donn mine les flux de traitement des donnes lorigine des prin-
ion d e
n t i ficat et flux d
2 Ide cipales positions comptables et des applications de base qui
s
ion s cl
licat supportent ces flux de traitement des donnes.
app
des
fication terfaces
ent i et in
Id Une fois les applications de base identifies, lauditeur
3
s
sque sintresse la qualit du systme de contrle. Il dtermine
es ri
ca t ion d cls
tifi les dabord si la conception du systme de contrle est adapte
Iden t contr
e la situation de risque actuelle des processus de lentreprise
4
ent
et enfin si les contrles prvus sont implments et sont
inem
hem efficaces.
de c
Test
5
rle
du cont Lvaluation du systme de contrle des processus mtiers
ption
nce
de la co pris en compte dans le cadre de laudit permet lauditeur
ua tion
6 Eval de savoir sil peut sappuyer sur les procdures de production
ont rle
du c des tats financiers et, le cas chant, de dfinir ltendue
ent
nem
tion des procdures daudit substantives supplmentaires quil
du fonc
on
uati doit effectuer.
7 Eval
le
loba
on g
ciati
A ppr
8
La prsente mthode ne traite pas, de manire explicite, les contrles IT gnraux. Lauditeur doit valuer et tester syst-
matiquement les contrles IT gnraux afin de dfinir une stratgie de test adapte aux contrles applicatifs. Les contrles
IT gnraux sont dans une large mesure dterminants pour savoir si un contrle applicatif, dont la conception est considre
comme effective, a fonctionn pendant toute la priode daudit, ou si lauditeur doit lvaluer explicitement, par exemple
par le biais de tests directs (par ex. procdures de validations dtailles).
La mthode de contrle repose sur un modle quatre niveaux. Ce modle est prsent de manire schmatique et simpli-
fie ci-aprs. Dans la ralit, les interactions peuvent tre beaucoup plus complexes, la schmatisation permet simplement
de comprendre lapproche de contrle.
5
Dlimitation de lapproche de contrle
par la mthode
Contrles dapplications IT
couvert
tio ns Intgralit
tra nsac Exactitude
ier /
us mt Validit
Pro cess
Autorisation
res
Sparation des fonctions
nci
fina
ons
licati
Contrles IT gnraux App
Environnement de
es
onn
par la mthode
contrle IT (polices, de d
non couvert
ase
directives) e/b
dle war
Dveloppement de Mid
programmes eau
/ rs
Modifications IT
ita tion
Exploitation IT explo
sd
me
Gestion des accs Syst
Scurit des systmes
Scurit des donnes
La figure ci-dessus montre, sous forme simplifie, le modle en couches utilis dans la prsente approche de contrle.
Chacune des quatre couches reprsente un type de processus et de ressource.

La couche suprieure (bleue) contient les principaux processus (manuels) de lentreprise prsents typiquement par
domaines dactivits et subdiviss en sous-processus et en activits individuelles.
La deuxime couche (rouge) contient les lments automatiss des processus de lentreprise, les applications IT
proprement parler. A lexception peut-tre des PME de petite taille, la majorit des oprations commerciales dans toutes
les entreprises est traite laide dapplications IT.
La troisime couche (jaune) contient les systmes IT de base. Ce terme recouvre une grande diversit de plates-formes
possibles supportant les applications de la deuxime couche. Exemple: systmes de gestion de base de donnes (par ex.
Oracle, DB2), composants de base dapplications intgres (par ex. SAP Basis, Avaloq, ) ou des systmes plus techniques
(par ex. Middleware).
La couche infrieure (verte) contient les lments dinfrastructure informatique. Pour lessentiel, cette couche contient les
lments matriels (Mainframe, systmes priphriques, serveurs) ainsi que les composants du rseau et les systmes de
surveillance technique y relatifs.
Lapproche prsente dans ce document traite principalement des deux couches suprieures (signales par une flche verte)
autrement dit, des contrles lis aux applications au sein des processus mtiers et des applications sous-jacents. Les deux
dernires couches, linfrastructure IT et les processus IT sous-jacents (signals par une flche rouge) sont bien entendu
importants du point de vue de lauditeur mais ne sont pas traits dans le cadre prsent.
6
1 Analyse du bilan et du compte de rsultats
Vue densemble
Contenu et Nous considrons que lobjectif de contrle est la conformit de la tenue de la comptabilit. La procdure
objectif est la suivante:
dfinition des positions du bilan et du compte de rsultats pertinentes pour laudit
identification des transactions (oprations commerciales) ou des classes de transaction1 lorigine de
ces positions.
Contexte Lanalyse2 du bilan et du compte de rsultats est centrale dans le cadre dun audit cibl et orient sur les
risques, et sert identifier les positions du bilan et du compte de rsultats pertinentes, cest--dire im-
portantes pour laudit. Lanalyse fournit lauditeur des informations cls pour lidentification des risques
et lidentification des dveloppements ayant une influence sur les comptes annuels. Elle sert en mme
temps dinstrument de planification pour la dfinition des points de contrle principaux et des mthodes
de vrification2 utilises.
Procdure
Principaux comptes
par ex. dbiteurs
RISQUE Assertions dans les

tats financiers,
RISQUE
par ex.:
Authenticit
RISQUE
valuation
ier
RISQUE
mt Intgralit
us
Pro cess
Droits et obligations
ions
licat
App
ing
Train
ACS
s IT IT
me
Syst
re IT
uctu
astr
Infr
1
Une classe de transaction est un ensemble de transactions ou doprations commerciales au sein dun processus dentreprise qui reposent sur une mme
base et qui peuvent tre comptabilises de manire quasiment identique.
2
Manuel suisse daudit, 1998, chapitre 3.2424 Analyse des comptes annuels
7
Identification des comptes et groupes de comptes significatifs
Lauditeur procde une valuation des risques pouvant avoir une influence sur les tats financiers en orientant ses proc-
dures daudit sur ces risques. A cet gard, la dfinition du caractre significatif joue un rle central.
Il sagit didentifier les comptes ou les groupes de comptes qui dpassent le seuil de matrialit3 et par consquent entrent
dans le champ daudit.
Sont galement identifis les comptes ou les groupes de comptes dont lexistence ou les volutions comportent des risques
spcifiques ou signalent des risques spcifiques, par exemple une volution inattendue de certains indicateurs.
Identification des transactions et des classes de transactions significatives
Une fois les groupes de compte identifis, lauditeur peut, dans une deuxime phase, analyser les transactions ou classes de
transactions qui ont un impact significatif sur ces comptes. Il peut tre judicieux ici de rechercher, sur la base dune analyse
de donnes, les critures qui ont t effectues sur certains comptes spcifiques. Il est alors possible de dduire de ces
donnes quelles oprations commerciales ou transactions ont t lorigine de ces critures. Cela peut seffectuer dans un
environnement ERP en rpartissant les critures lectroniques dans les comptes significatifs par code transaction.
Lauditeur remonte ainsi des principaux comptes et groupes de comptes au travers des principales transactions aux opra-
tions partir desquelles ces transactions ont t gnres.
Lavantage de cette approche rtrospective est quelle exclut demble les classes de transactions non significatives rsultant
des subdivisions de processus. Lorsque lauditeur connat les classes de transactions significatives et les oprations commer-
ciales qui les gnrent, il peut procder lanalyse des risques aux diffrentes tapes du processus comme dcrit ltape
suivante.
Particularits
Dans le cadre du contrle des applications IT, lauditeur se concentre gnralement sur les transactions de routine sachant
que la plupart dentre elles sont gres par lapplication et que cest l quont lieu la plupart des contrles automatiss et
ceux lis aux systmes informatiques. Les transactions non routinires, en particulier les procdures destimation, font fr-
quemment lobjet dun systme de contrle principalement manuel.
Lauditeur devrait, ce stade de sa mission, prendre galement en compte les principaux vnements de lentreprise qui ont
eu une influence sur les comptes ou classes de transactions slectionns. Ex.:
introduction dune nouvelle application informatique
migration ou regroupement dapplications ou de donnes
3
Manuel suisse daudit, 1998, chapitre 3.114: Ont un caractre significatif, tous les lments qui influencent lvaluation et la prsentation des comptes
individuels, des comptes du groupe ou certains de leurs postes, modifiant ainsi lassertion au point dinfluencer les dcisions des destinataires des comptes
individuels ou des comptes du groupe concernant lentreprise.
8
2 Identification des processus mtier

et des flux de traitement des donnes
Vue densemble
Contenu et Identification des processus mtiers significatifs qui sont lorigine des transactions et classes de transac-
objectif tions prcdemment identifies. Par processus mtiers significatifs on entend les principaux processus
qui ont une influence directe sur le flux de traitement comptable. Il sagit du processus de comptabilit
en tant que tel, de processus mtiers complexes tels que la facturation et les processus de support, par
ex. dans le domaine des ressources humaines. Les processus IT tels que dfinis dans COBIT par exemple
ne sont pas concerns4.
Contexte Les tats financiers dune entreprise sont le rsultat de la consolidation de plusieurs activits que lon peut
regrouper en processus et qui peuvent tre trs diffrents les uns des autres (processus complexes, limi-
ts dans le temps; processus pouvant influencer plusieurs transactions, etc.). Potentiellement, certaines
faiblesses de ces processus peuvent remettre en cause la fiabilit des tats financiers. Cest pourquoi une
identification minutieuse des processus mtiers et des flux de traitement des donnes est indispensable
pour pouvoir valuer les risques au sein de chaque processus.
Procdure
Identification des processus significatifs
Sur la base des transactions identifies, lauditeur identifie les processus qui influent sur ces positions. Lanalyse stend
par exemple du processus ponctuel de clture des comptes annuels (avec influence directe sur le montant dune provision)
jusqu un processus de vente et de facturation complexe qui influence le flux de marchandises et le flux financier. Dans ce
dernier cas, plusieurs positions du bilan et du compte de rsultat auront le mme processus comme source.
Les processus peuvent judicieusement tre reprsents sous forme de cartographie de processus dans un tableau ou un gra-
phique. Les deux formes de reprsentation prsentent des avantages quil peut tre utile de combiner en cas dinteractions
de processus complexes.
Utilisation de la documentation existante
Si disponible, lauditeur doit sappuyer sur la documentation des processus existante auprs de lentreprise. La documen-
tation se concentre gnralement sur les activits et prcise, pour chaque tape de processus, les entres, les traitements
et rsultats ainsi que les rles des diffrents acteurs. Toutefois, ce type de documentation contient rarement les risques de
processus ou les contrles cls, ceux-ci doivent donc tre identifis et documents par lauditeur dans une phase ultrieure
des travaux lis aux contrles des applications.
Cration dune nouvelle documentation formes de reprsentation
Lauditeur doit acqurir une connaissance approfondie des processus slectionns. Il convient, cet gard, de distinguer
les processus mtier (par ex. processus de vente) et les processus financiers parfois trs ponctuels (par ex. consolidation des
chiffres trimestriels dune succursale ou calcul de lamortissement annuel dune immobilisation). Ces deux catgories de
processus comportent des risques susceptibles de se matrialiser dans les tats financiers.
4
Un processus peut tre dfini comme une chane de tches manuelles, semi-manuelles ou automatises servant llaboration ou au traitement
dinformations, de produits ou de services. Exemples: vente, relance, production, inventaire, comptabilit, etc..
9
Prsentation sous forme de tableau. solution adapte des lments comptables et interactions simples.
Position de bilan ou du Montant en milliers Rsultat (Output) Processus Entre (Input)

compte de rsultats de CHF
Chiffre daffaires 675123 Factures Vente Contrats,
services
fournis
Cots 422234 Paiements Achat Commandes
Inventaire 57000
Equipements 121000
Crditeurs 45000
Frais de personnel 121111 Paiements Gestion ressources Contrats,
Assurances 13000 humaines services
Etc
Immobilisation 121000 Amortissement Bouclement Valeur
Divers Positions consoli- Consolidation Positions
des dune filiale
Prsentation sous forme de graphique (forme de flux de traitement) - solution adapte

des interactions complexes
Exemple A
es
Sal
ic
teg
ials Strasales
ter e-
Maanag t
m n
n me
ctio ed n
du ing
nish tive
Pro Eng
in eer F i
duc
tio era
Op sales
ork ng pro
ials W duli
ter e-
e
sch P
Maanag t MR
- m men
cha
Pursing r
Rawrials
Job ation me
gic par sto
Cu
te
Stra hasin
g
te pre
purc ma ing
P Sh opp
MR
e
ous
reh
ting g Wa
era in
Op rchas
pu
ng
Billi
tion
duc
Pro ory g
ent
Inv ountin
se acc
rehou
Wa
l ts
r na g oun le
Inte untin Acc eivab
o
ods acc rec
Go cept
re
ory g
or ent
d Inv ountin
Ven acc
e
ng
nti
oic n
Inv catio
ver
tifi
ou
GL nting Acc
ng
olli
u
cco
ntr
a
Co
t
ets g cos t
Ass untin ad
rhe eme
n
acc
o Ove anag
m
ts
oun
Accayable
p
10
Exemple B
Processus de pilotage
Corporate Governance Processus de dfinition des objectifs Contrle de gestion
Stratgie Organisation dentreprise Gestion du personnel
Category Management (CM)
Acquisition (achat/dispatching)
March
March
Logistique
Vente
Processus de support
Finances/Services Informatique Personnel/formation
Communication Gestion de la qualit Gestion immobilire
Gestion des emplacements Services internes Production
Prsentation graphique (forme de flux de traitement des donnes). En cas danalyse dinteractions complexes.
11
Particularits
Degr de dtail
Une description trop gnrale rend difficile lidentification des risques. Inversement, un degr de dtail trop lev peut nuire
lanalyse et la lisibilit. Selon la complexit dun processus, il peut tre utile de le subdiviser en plusieurs sous-processus.
Exemples
Le processus dachat est compos des sous-processus gestion des donnes de base fournisseurs, facturation fournis-
seurs et comptabilisation des achats.
Le processus de vente est compos des sous-processus gestion des donnes de base clients, facturation clients et comp-
tabilisation des ventes.
Le processus de salaire est compos des sous-processus gestion des donnes de personnel, prparation du dcompte
du salaire, fixation du salaire, dcompte du salaire et comptabilisation du salaire.
Gestion des paramtres et des donnes de base
Pour certains processus mtiers, il est conseill de considrer la gestion (premire saisie, mutations et suppression) des pa-
ramtres et des donnes de base comme deux sous-processus distincts.
Les paramtres dune application IT sont les valeurs constantes utilises pour un mme type de transaction (par ex. taux
de retenue pour la caisse de pension dans une application de calcul de salaire).
Les donnes de base sont les attributs permanents dun objet, par ex. donnes de base crditeurs, donnes de base clients,
donnes de base produits
Interfaces manuelles
Lobjectif de cette tape est de comprendre le flux de traitement des informations et des donnes pertinentes. Il ne sagit
pas de considrer uniquement les donnes lectroniques; une analyse complte prend galement en compte des flux de
documents (par ex. rapport sur lvaluation des stocks) et des interfaces manuelles.
12
3 Identification des applications de base

et des principales interfaces IT pertinentes
Vue densemble
Contenu et Identification des applications IT concernes et de leurs interfaces

objectif
tier
s m
essu
Proc
ion s
licat
App
s IT
me
Syst
e IT
u ctur
astr
Infr

ITA
CS
Tr
ai
nin
g
Contexte De nombreux contrles sont automatiss et intgrs dans les applications IT. De plus, lautomatisation
des tapes de processus prsente des risques inhrents supplmentaires. Il peut sagir par exemple de la
difficult de mettre en uvre une sparation adquate des fonctions, mais galement dune impossibi-
lit de contrle humain compte tenu du niveau lev dintgration, du traitement en temps rel et du
principe de single point of entry, lesquels gnrent un traitement et un enregistrement automatiques
des transactions.
Il est donc utile didentifier temps les applications impliques, leurs caractristiques et leurs interfaces.
Ces informations permettent de dfinir de manire dtaille ltendue de laudit et dlaborer un pro-
gramme daudit.
13
Procdure
Elaboration dune cartographie des applications
Une reprsentation des applications impliques nest pas toujours superposable avec le flux des donnes. En particulier avec
les applications fortement intgres (par ex. Enterprise Resource Planning Systems, ERP), plusieurs processus mtiers sont pris
en charge par une seule et mme application (par ex. couplage automatique dun processus dachat avec un processus de
vente).
Exemple
SALAIRE
COMPTA
EXCEL
FACTURE
Inventaire et catgorisation des applications pertinentes du point de vue financier
Nous distinguons les diffrents types dapplications ci-aprs. Compte tenu de leurs profils de risque trs diffrents, les types
de programmes sont une caractristique importante pour la planification et la ralisation de laudit et doivent donc tre
documents:
application standard
application standard fortement adapte
dveloppement interne
14
Applications standard
Les applications standard au bnfice dune certaine maturit prsentent gnralement une multitude de contrles
intgrs pertinents. Le tableau ci-aprs montre, titre dexemple, quelques contrles de base destins assurer lintgrit
des transactions traites:
Une application de comptabilit Ces fonctionnalits offrent (ou impliquent) les contrles suivants
standard devrait disposer des
fonctionnalits suivantes (liste non
exhaustive)
Datation automatique des opration Protection de laccs aux paramtres de la date systme
et des transactions par le systme
Offrir plusieurs identifications Cryptage du mot de passe
utilisateurs avec des mcanismes
dauthentification Contrle de la syntaxe du mot de passe
Contrle de la validit du mot de passe
Historique des tentatives de connexion choues

Paramtrisation des autorisations Mcanisme de protection daccs par des profils de groupe ou des autorisa-
tions individuelles.
Traces des mutations des paramtres Enregistrement automatique des anciennes valeurs dans un fichier historique
et des donnes de base (paramtres de (avec date de validit: valable ds le / jusquau, date de la mutation et identi-
scurit, plan de comptes, donnes de fication de lutilisateur qui a effectu la modification)
base crditeurs et dbiteurs, etc.)
Protection des accs aux paramtres et au fichier historique.
Interdiction de supprimer Le programme ne doit pas proposer de fonction de suppression des

donnes.
En outre, les contrles numrs ci-dessous sont galement trs importants:

valider les donnes (par ex. listes de slection, formules de validation, etc.),
piloter le traitement (job control, ordre de traitement journalier, mensuel, de fin danne, etc.),
droulement des transactions (par ex. gestion du workflow, contrles des limites, principes des 4 yeux et signature lec-
tronique, vrification de la concordance entre commande/livraison/facture),
grer les dpenses (disponibilit des rapports, etc.).
Lors de lvaluation des applications standard il convient de rpondre par ex. aux questions suivantes:
quel type dapplication standard lentreprise utilise-t-elle?
lapplication standard est-elle rpandue dans son secteur dactivit?
lapplication standard est-elle certifie?
sagit-il dun progiciel tabli, connu ou dune nouveaut?
existe-t-il des sources dinformations sur cette application et, ventuellement, des faiblesses de scurit ou de processus
connues (remarque: les applications standards contiennent parfois des erreurs et lauditeur doit disposer dune connais-
sance suffisante sur les sources derreur connues).
lauditeur dispose-t-il de connaissances et dexpriences personnelles relatives lapplication?
15
Les rponses servent, conformment la norme NAS 310 chiffre 10, lidentification des domaines requrant une at-
tention ou une connaissance particulires. Elles fournissent lauditeur un aperu des risques inhrents lapplication
utilise.
Si lauditeur conclut que lapplication standard ne prsente pas de faiblesses connues dans les domaines qui le concernent,
il peut limiter ses efforts dans les tapes suivantes de lapproche daudit des applications au niveau de lidentification des
risques et lvaluation des contrles pertinents. Au minimum, il doit sassurer que:
les contrles sur lesquels il compte sappuyer existent et fonctionnent
en cas de paramtres dapplication, que ceux-ci taient actifs pendant la priode daudit concerne.
Applications standard fortement adaptes
Par applications standard fortement adaptes, nous entendons des progiciels dont le but principal est de mettre dis-
position des fonctionnalits de base et des outils de cration de processus et de workflows, et dont la paramtrisation
permet la mise en place de solutions spcifiques qui rpondent aux besoins de lentreprise. Lauditeur est ici confront
un grand dfi dans la mesure o, mme sil dispose dinformations sur la fiabilit des composants des applications et sy-
stmes prouvs, il nen a pas sur linteraction de ces composants avec les ventuelles configurations et programmations
supplmentaires dans lenvironnement spcifique du client. En pareilles situations, lauditeur devra prvoir davantage de
temps pour lidentification des risques et lvaluation des contrles pertinents. Plus une application standard a t adapte
aux exigences spcifiques dune entreprise, plus lanalyse des paramtres, de la gestion du workflow et des adaptations
techniques des programmes est importante.
Dveloppements internes
Dans le cas de dveloppements internes, lauditeur nest pas en mesure de sappuyer sur les informations et les expriences
gnralement connues et doit adapter sa procdure daudit lapplication concerne. Les applications dveloppes en in-
terne exigent gnralement un travail de vrification plus important. En pareilles situations, la collaboration entre lauditeur,
le responsable de lapplication et, le cas chant, le dveloppeur de lapplication revt une grande importance.
Dans le cas dapplications standards fortement adaptes et dapplications dveloppes en interne, lauditeur sappuiera,
pour des raisons defficacit, et dans la mesure du possible, sur des tests documents au sein de lentreprise. Si les tests
correspondant nexistent pas ou ne sont pas pertinents (concept ou documentation de test lacunaires, erreurs non corriges
aprs les tests, absence de prise en main formelle par les utilisateurs, etc.), il doit raliser lui-mme les tests ncessaires
sa vrification.
Exploitation de lapplication par des tiers ou au sein de lentreprise
Lexternalisation de domaines dactivits ou de processus mtiers comporte des risques inhrents et des risques daudit
supplmentaires compte tenu de la dlgation de responsabilit. La question de lorganisation dun audit chez le prestataire
de services est particulirement pertinente: le standard de vrification NAS 402 (ou SAS 70) doit tre pris en compte dans
ce cas.
16
Utilisation centralise ou dcentralise de lapplication
De mme, en raison des responsabilits dlgues mais galement dune complexit technique souvent considrable (par
ex. en termes dintgrit lie des procdures de sauvegardes redondantes des donnes ou des squences de traitement
au travers de plusieurs priodes ou zones temporelles diffrentes), lutilisation dcentralise dune application comporte des
risques inhrents et des risques daudit supplmentaires qui augmentent la complexit de laudit.
Reprsentation des informations
Reprsentation sous forme de tableau
Position Montant Processus Application Commentaire / pr- Type Exploitation Utilisation

de bilan en millier utilise systmes
CA 675123 Facturation SAP FI Interfaces FACTURE Standard Int. Centralise

et LIVRAISON
Salaires 59123 Gestion du SAP HR ASP extern Standard Out. Centralise
personnel
Inventaire des principales interfaces
Les interfaces dentre et de sortie dune application de type financier doivent tre considres comme des sources de ris-
que. Il est important de les identifier et de les contrler.
Nom de Type Applications en Type de flux Frquence Listes derreur Evaluation

linterface amont/aval des risques
17
4 Identification des risques et des contrles cls
Vue densemble
Contenu et Cette tape consiste dlimiter le primtre daudit qui sera ensuite valu et test. Elle consiste notam-
objectif ment dfinir pour chaque risque significatif des scnarios derreurs, afin dvaluer la manire dont ils
peuvent tre compenss par des contrles cls. Il sagit donc la fois de rduire limpact et la probabilit
de survenance de ces erreurs. Par ailleurs, limpact sur les assertions dans les tats financiers est gale-
ment analys (par ex. exhaustivit, authenticit, valuation, rattachement lexercice ou reprsentation
dans les comptes annuels).
r
tie
ess us m
Proc
ion s
licat
App
s IT
me
Syst
e IT
uctur = Risques
astr
Infr
= Contrle

ITA
CS
Tr
ai
ni
ng
Contexte Compte tenu de la complexit des processus et des applications, il est important de se concentrer sur
lessentiel lors des travaux daudit. Lidentification des risques et des contrles cls attendus constitue la
base pour un audit efficace.
Les contrles cls attendus par lauditeur sont ensuite compars aux contrles effectivement implmen-
ts et la couverture des risques est value.
18
Procdure
Risques, objectifs de contrle et contrles
Au sein des principaux processus et des systmes impliqus, les risques qui peuvent entraner une inexactitude importante
dans les tats financiers sont identifis. Le rsultat obtenu est un aperu des risques susceptibles dempcher la ralisation
des objectifs du processus. Cette analyse des risques permet galement de dfinir ltendue des procdures daudit.
Les objectifs de contrle dcoulent des risques. Un objectif de contrle est dfini comme une assertion relative au rsultat
souhait (but) devant tre atteint grce limplmentation du contrle. Les objectifs de contrle sont donc souvent des
risques inverss, autrement dit, ils visent la diminution dun risque donn.
Par la suite, lauditeur dfinit les attentes relatives aux contrles typiques et attendus pour les risques identifis. Il convient
de subdiviser ces contrles en contrles cls et autres contrles. Les contrles cls, individuels ou combins entre eux,
sont indispensables une rduction acceptable des risques. Ils sont donc garants de la fiabilit des rsultats du processus
et des donnes financires. Les contrles cls constituent la colonne vertbrale du systme de contrle et sont donc des
objets de vrification essentiels. Les autres contrles ont une pertinence moindre pour lauditeur.
Les contrles cls attendus par lauditeur sont compars aux contrles effectivement mis en place et la couverture des ris-
ques est value dans le cadre des contrles cls existants dans le processus concern.
Frameworks standard
Il existe des inventaires gnriques de risques typiques, des objectifs de contrle et des pratiques de contrle pour divers
processus et applications. Le Framework COBIT en est un exemple connu dans le domaine des processus informatiques.
Un autre exemple de contrles dapplication gnriques est illustr dans lannexe 1. Ces moyens auxiliaires peuvent tre trs
utiles lors de laudit mais ne remplacent pas le jugement professionnel de lauditeur lors de lvaluation du processus.
Types de contrle
Les questions suivantes sont pertinentes pour le droulement de laudit et doivent donc tre documentes:
contrles prventifs versus contrles dtectifs: le but dun contrle cl est-il dempcher la survenance dune erreur ou de
la dtecter?
contrles automatiques versus contrles manuels: un contrle est-il ralis manuellement ou est-il automatis dans une
application?
19
Prsentation des informations
La matrice des risques et des contrles prsente dans la partie gauche les risques identifis et leur couverture par les con-
trles5:
Risques Contrles Acti- Assertions dans les tats financiers6 Im- Efficacit des contrles
vit pact
Quest- Qui con- Concep- Fonctionne- Efficacit
ce qui trle quoi, tion des ment des
Principe du justificatif
pourrait comment? contles contles
Dlimitation priode
Droits et obligations
se pas- Le contrle Les con- Oui / non

ser? Comptabilisation trles sont- / n.a.
Oprationnelle
est-il
Conservation
Historisation
Authenticit
Autorisation capable de ils raliss?
Auditabilit
Imputation
Evaluation
remplir les
Contrle
Prventif
Dtectif
critres?
Un lment supplmentaire au centre de cette matrice des risques et des contrles permet dindiquer lassertion6 des tats
financiers concerns par le contrle cl. Cela garantit la couverture de toutes les exigences par les contrles identifis.
La partie droite de la matrice peut servir dans les tapes suivantes de lapproche daudit documenter lvaluation de la
conception des contrles et lvaluation de leur fonctionnement.
Particularits
Exhaustivit des risques et des contrles
Lidentification des contrles au sein des transactions nest pas suffisante en soi; il convient galement de considrer les
risques et les contrles inhrents aux paramtres et aux donnes de base. Les contrles typiques sont les contrles daccs
et les autorisations.
Tous les contrles importants lis aux applications doivent tre pris en compte, autrement dit, tous les contrles manuels
ou automatiques qui ont une influence directe sur le rsultat du processus. La qualit des contrles ayant une influence
indirecte (par ex. les contrles IT gnraux) doit tre value dans le cadre de lapprciation globale de laudit mais ne fait
pas lobjet dexplications plus dtailles dans ce document.
Lefficacit des contrles est examine dans les tapes dcrites au chapitre 7.
5
Il existe galement diffrents modles de rfrence concernant les assertions dans les tats financiers, par ex. celui du Manuel suisse daudit 1998.
6
20
Concentration sur les contrles cls
Si lauditeur ne se concentre pas sur les contrles cls, laudit risque dtre trop gnral et inefficace. De mme, une descrip-
tion trop dtaille des contrles attendus est dconseille, car elle entranerait des cots subsquents trop levs et serait
sans rel intrt supplmentaire.
Documentation des contrles dapplication
Pour la comprhension des contrles applicatifs et en particulier pour lvaluation ultrieure de la conception des contrles,
une documentation approprie des contrles revt une importance fondamentale. La documentation doit permettre
lauditeur de comprendre quelles sont les rgles de gestion devant tre garanties par le contrle. De plus, elle doit faire
apparatre les dcisions lies la conception du contrle prises dans la perspective de limplmentation du contrle. Enfin,
elle doit faire tat des paramtres ou des rglages personnaliss pertinents pour que le contrle puisse se drouler confor-
mment aux rgles de gestion dfinies.
Le tableau ci-dessous prsente deux exemples:
Description 3-Way Match Sparation des fonctions

Rgle de gestion Aucune facture nest paye si la comman- Sparation des fonctions entre comptables
de, le bon de commande et la facture ne dbiteurs et crditeurs. Les personnes qui
concordent pas (tolrance de 10%) paient les factures ne peuvent pas crer de
nouveaux fournisseurs
Conception du contrle Rfrence la fonction 3-Way-Match dERP Rles spars des comptables dbiteurs et
crditeurs et pour la gestion des donnes
de base.
Documentation dune matrice de sparation
des fonctions
21
5 Tests de cheminement
Vue densemble
Contenu et Avant dentreprendre un test de cheminement, le processus global doit tre compris, du dbut la fin.
objectif Le test de cheminement consiste effectuer et documenter les tapes manuelles/automatiques du
processus ou de la classe de transaction sur la base dune transaction type servant dexemple. Il sert
vrifier la comprhension du processus concern, les risques et les contrles y relatifs mais galement
confirmer lanalyse prcdente.
La profondeur, respectivement le degr de dtail avec lequel un test de cheminement est effectu, d-
pend de lintention de lauditeur de sappuyer ou non sur le systme de contrle existant.
Si lauditeur a lintention de sappuyer sur les contrles, il analysera en dtail le fonctionnement des
diffrents contrles pendant le test de cheminement afin de savoir sils couvrent effectivement les
risques existants ou non.
Si lauditeur na pas lintention de sappuyer sur lefficacit des contrles, il se contentera dun test de
cheminement moins dtaill. Il doit garantir que lauditeur comprend tous les risques principaux (finan-
ciers) pouvant rsulter du processus. Dans ce cas, il dduira ses procdures daudit orientes rsultat
partir des risques identifis.
Contexte Le test de cheminement permet de vrifier systmatiquement:

la comprhension des flux de traitement,
la consistance et la pertinence de la documentation et du diagramme de flux existants,
la correction et lexhaustivit des informations sur les contrles pertinents et
lexistence des contrles pertinents dans les activits quotidiennes.
Procdure
Donnes de flux
Une transaction est slectionne par classe de transaction. Son traitement est analys via le processus global, en commen-
ant par linitiation de la transaction et son autorisation, son enregistrement, son traitement, jusqu sa comptabilisation.
Le processus / la classe de transaction doit tre suivi(e) partir du fait gnrateur, puis au travers des diffrentes tapes
de traitement dans lapplication. Lors du droulement du processus, les contrles existants sont vrifis et la slection de
contrles cls analyse.
Dans le cadre du test de cheminement, le personnel doit tre interrog sur sa comprhension des descriptions de fonction
et des consignes de contrle, en particulier en ce qui concerne le traitement des exceptions dans le processus ou les traite-
ments des erreurs.
Questions devant tre prises en compte durant le test de cheminement du processus:

qui faire appel pour obtenir des explications sur les dtails, par ex. du domaine dactivit?
de qui / do proviennent les documents, rapports, diagrammes de flux, copies dcran etc. existants?
quelle activit de contrle a lieu au cours des diffrentes activits?
laudit est-il effectu pour viter une erreur ou pour lidentifier?
comment et quelle frquence le contrle est-il effectu (automatique ou manuel)?
le contrle automatique est-il rellement oprationnel?
quelles traces le contrle laisse-t-il?
22
La documentation du test de cheminement, durant lequel les tapes manuelles ou automatiques du processus ou de la
classe de transaction sont vrifies, est normalement labore sur la base de descriptions, diagrammes de flux, de copies
dcran, de documents, etc.
Particularits
Dans la pratique, le test de cheminement saccompagne souvent de lvaluation de la conception du contrle et, dans le
cas de contrles automatiques, galement de lvaluation du fonctionnement des contrles. Dans la prsente approche
daudit, ces deux tapes constituent la suite logique du test de cheminement et sont traites sparment dans les deux
chapitres suivants.
Les tests de cheminement sont souvent diviss en plusieurs parties. Cest pourquoi, au cours du droulement des sous-
processus ou des applications individuelles, les interfaces qui les relient sont souvent oublies.
23
6 Evaluation de la conception des contrles
Vue densemble
Contenu et Dans les prcdentes tapes, lauditeur a identifi les principaux risques et contrles cls et a acquis une
objectif comprhension approfondie du processus qui a t vrifie dans le cadre du test de cheminement.
Ladquation des diffrents contrles, pris individuellement, a fait lobjet dun premier examen.
Lvaluation de la conception des contrles qui suit (design effectiveness) examine ladquation (couver-
ture des risques, exhaustivit, actualit) et lefficacit conomique (redondances, chevauchements) de
lensemble du systme de contrle interne en tenant compte des principaux processus mtier dans leur
globalit. La conception des contrles, notamment leur positionnement dans le processus mtier, doit
tre value pour savoir si:
les risques identifis sont entirement couverts,
les objectifs de contrle dfinis peuvent tre rellement atteints par les contrles mis en place,
les contrles permettent rellement de rduire les risques derreur et de fraude et si la couverture des
risques seffectue de manire efficace et conomique,
ou si, le cas chant, un autre contrle ou combinaison de contrles, notamment de contrles au ni-
veau de lenvironnement de lentreprise, est plus efficace pour raliser le mme objectif de contrle.
Le but de cette tape consiste atteindre une qualit de contrle adquate avec le moins possible de
contrles.
Seule une comprhension approfondie de la conception des contrles permet de dfinir une stratgie
daudit approprie pour lvaluation du fonctionnement des contrles.
Contexte Une analyse minutieuse de la conception des contrles (Design Effectiveness) permet:
didentifier les lacunes, les chevauchements et les doublons en matire de contrles;
dviter la ralisation onreuse de contrles par les services et, le cas chant, les tests de fonctionne-
ment (Operating Effectiveness) des contrles par lauditeur en cas de contrles inappropris;
denvisager que le mme rsultat ou un meilleur rsultat peut tre obtenu avec lutilisation ou
ladaptation dautres contrles, notamment de contrles dj tablis.
Procdure
Evaluation de la conception des contrles
Le systme de contrle interne est prsum effectif lorsque les contrles sont respects et donnent une assurance raison-
nable que les erreurs ou les abus naffectent pas de manire significative les tats financiers. Certaines procdures daudit
orientes processus sont conues pour attester que la conception des contrles permet didentifier, dviter et de corriger
des erreurs importantes. Les lments probants defficacit des contrles durant toute la priode sous revue ne peuvent tre
apports qu ltape suivante Evaluation du fonctionnement des contrles7.
PS 400: Evaluation des risques et contrle interne RZ27.

7
24
Procdures daudit
Les procdures daudit dvaluation de la conception des contrles comportent des questions, des observations, des tests de
cheminement, la revue de la documentation principale et lvaluation de ladquation de contrles spcifiques. Lauditeur
forme son opinion sur la conception des contrles en:
interrogeant les membres de la direction de lentreprise et les collaborateurs ayant des tches de surveillance ainsi que les
collaborateurs impliqus dans la ralisation du contrle;
consultant les documents relatifs aux transactions et les autres documents importants de lentreprise;
observant les activits spcifiques dexcution et de contrle;
suivant les transactions individuelles dans le systme dinformation (test de cheminement).
Conformment aux normes daudit en vigueur, les procdures daudit dvaluation de la conception des contrles Design
Effectiveness doivent tre documentes par des lments probants (vidences daudit).
Questions relatives lvaluation de la conception des contrles
Linterrogation des collaborateurs du domaine contrl laide de quelques questions types, permet parfois sous forme
dun processus itratif didentifier des faiblesses importantes dans la structure du contrle8.
Les tapes du processus et les contrles qui sy rapportent sont-ils organiss dans un ordre logique et judicieux?
La responsabilit de la ralisation des contrles est-elle dfinie sans ambigut?
Les contrles peuvent-ils tre raliss de manire correcte et judicieuse?
Les contrles hybrides ou entirement manuels sont-ils remplacs, dans la mesure du possible, par des contrles automa-
tiques?
Les contrles en aval, cest--dire dtectifs, sont-ils remplacs, quand cela est possible, par des contrles en amont, au-
trement dit prventifs?
Les contrles sont-ils conformes aux exigences des directives et des procdures de travail?
Les informations ncessaires la ralisation du contrle sont-elles disponibles?
Le droulement du processus ou du contrle permet-il ltablissement dun document de contrle comprhensible?
Les contrles sont-ils raliss par un agent qualifi et comptent dans ce domaine?
Les contrles sont-ils raliss dans un dlai adquat et avec une frquence approprie?
La conception des contrles peut-elle tre mise en uvre dans le cadre des restrictions organisationnelles et finan-
cires?
Une approche dite portefeuille de contrles permet dvaluer les contrles en termes de niveau dautomatisation (manuels,
semi-automatiques, automatiques), dimpact (prventifs, dtectifs), de frquence de contrle et de couverture de risque.
Concernant le niveau dautomatisation, les contrles automatiques sont plus efficaces que les contrles manuels car ils ont
un fonctionnement continu dans le temps et un cot dimplmentation unique. De plus, leur efficacit est plus stable tant
quaucune modification significative nest effectue dans lapplication.
Il est communment admis que les contrles prventifs permettent plus facilement datteindre les objectifs de contrle que
les contrles dtectifs qui visent lidentification derreurs en aval des traitements.
En rgle gnrale, une frquence leve de contrles manuels et semi-automatiques entrane des cots et des dlais
plus levs par rapport des contrles automatiques dont la frquence na pratiquement pas dinfluence sur les cots
dexploitation. En revanche, une frquence dexcution peu leve dun contrle manuel ou semi-automatique peut nuire
son efficacit. Un contrle qui couvre plusieurs objectifs de contrle ou diffrents risques est en principe considr comme
plus efficace, plus fiable et plus conomique quun contrle cibl sur un seul risque.
Menzies 2006, p 271 et s.

8
25
Questions techniques relatives lvaluation de la conception des contrles
Dans le cadre de lvaluation de la conception des contrles applicatifs, lauditeur clarifie les conditions techniques requises
pour que le contrle se droule comme prvu. Lauditeur se posera notamment les questions suivantes:
le contrle peut-il tre contourn ou forc (contournement, procdure dexception, super user)?
dans quelle mesure le contrle dpend-il de la paramtrisation?
dans quelle mesure le contrle dpend-il du systme dautorisation?
qui contrle le systme dautorisation?
dans quelle mesure le contrle dpend-il des donnes de base?
qui contrle les donnes de base?
le fonctionnement du contrle peut-il tre enregistr pour une vrification ultrieure (traces daudit)?
Particularits
Potentiel doptimisation
Pour prserver les aspects conomiques du systme de contrle, il faut se demander si les contrles dfinis sont ncessaires
et sils ne chevauchent pas dautres contrles de processus ou contrles au niveau de lentreprise(Entity level controls9) ou
ne sont pas redondants. Les contrles en amont, cest--dire les contrles prventifs, mais galement les contrles automa-
tiques reprsentent un potentiel dconomie considrable ainsi quune assurance leve au niveau de leur apprciation.
Il convient, pour identifier le potentiel damlioration de la conception des contrles, dutiliser le savoir et les expriences
provenant du domaine dactivit de lentreprise concerne, ainsi que les apprciations de la direction et des collaborateurs.
Outre les faiblesses dj connues, lanalyse des contrles au niveau de lentreprise offre un potentiel considrable
damlioration de la conception des contrles. Compte tenu de son influence globale sur lensemble des processus, ce po-
tentiel optimise les diffrents contrles du processus, les complte ou mme les remplace. Souvent, en raison des courts d-
lais impartis pour la mise en place de systmes de contrle interne, les objectifs de contrles sont raliss de manire redon-
dante dans le cadre de contrles de processus et de contrles au niveau de lentreprise. Il y a toutefois lieu de vrifier si
les contrles au niveau de lentrepriseassurent une raction immdiate ou sils ne sont en mesure dapporter une rponse
adquate qu moyen terme. Dautres redondances et chevauchements peuvent tre identifis lors de lharmonisation de
la conception des contrles dans les processus mtiers et de support.
Les contrles au niveau de lentreprise tels que par exemple les contrles IT gnraux ont une porte globale dans lentreprise ou dans le groupe et sont
9
habituellement grs dans les dimensions du cube COSO suivantes: lenvironnement de contrle, lvaluation des risques, le systme dinformation et la
communication ainsi que la surveillance. Il sagit de directives et de procdures internes toute lentreprise ayant une porte considrable sur la confor-
mit de lactivit commerciale en termes de stratgie, dobjectifs ou daspects culturels. A linverse des contrles de processus, les contrles au niveau de
lentreprise (en gnral) ont une porte abstraite mais plus large. [Menzies 2006, p. 21].
26
Contrles cls inoprants
Dans le cadre de son apprciation de la conception des contrles, lorsque lauditeur identifie des contrles cls quil con-
sidre comme inoprants, le systme de contrle valuer prsente alors une lacune. Pour la combler, il doit identifier
dautres contrles cls ou des contrles compensatoires et valuer leur efficacit. Dans ce cas, lauditeur doit toujours garder
lesprit la slection complte de contrles cls pour viter de crer des redondances coteuses.
Effort de test
Une adaptation de la slection des contrles cls simpose galement lorsquil apparat, lors du test de cheminement ou de
lvaluation de la conception des contrles, que leffort pour tester un contrle cl est disproportionn.
27
7 Evaluation du fonctionnement des contrles
Vue densemble
Contenu et Lvaluation du fonctionnement des contrles (Test of Operating Effectiveness, TOE) permet lauditeur
objectif dmettre une opinion sur le systme de contrle interne. Elle vise dfinir lefficacit dun contrle
(Operating Effectiveness) en valuant que le contrle fonctionne comme prvu et quil a t excut
entirement par une personne qualifie et autorise10.
Contexte Seul le test de fonctionnement des contrles fournit au management responsable et lauditeur
lassurance ncessaire pour apprcier le fonctionnement rel des contrles pendant toute la priode
daudit, la couverture des risques et des objectifs de contrles. La ncessit et ltendue des tests dcou-
lent de la stratgie daudit.
Procdure
Etapes de lvaluation
Lvaluation du fonctionnement des contrles comprend les tapes suivantes:

slection des contrles vrifier, dans la mesure o il nest pas ncessaire de contrler lensemble des contrles
choix de la stratgie de test (procdures daudit orientes processus contre procdures daudit orientes rsultat)
choix de la procdure de test, et notamment de la taille de lchantillon
ralisation des oprations daudit orientes processus ou orientes rsultat
evaluation des exceptions releves et de limportance des erreurs et des faiblesses constates
Procdure de contrles oriente rsultat pour lobtention dlments probants (vidences daudit)
Lauditeur obtient des lments probants pour lvaluation des contrles par le biais de procdures daudit orientes rsultat.
Ces activits se subdivisent en contrles ponctuels (revue denregistrements ou de documents, observation, questions ou
confirmations, recalcul, mise en application ou rptition du contrle) et procdures daudit analytiques (par ex. au moyen
dune analyse des donnes)11. Gnralement, lobservation et le questionnement ne garantissent quune assurance daudit
moyenne. Les contrles ponctuels sont utiliss en particulier pour les contrles faiblement documents ou pas documents.
En revanche, la vrification ou la rptition dun contrle ponctuel garantissent un niveau dassurance daudit lev. Les
contrles manuels sont gnralement tests au moyen dune combinaison de questions, dobservations, de consultations
des documents de contrle et, si ncessaire, par la rptition du contrle.
Stratgies de test dans le cadre des contrles dapplication
Test unique (Test-of-One): un contrle programm doit en principe tre test une seule fois. Aprs quoi on considre,
condition que lenvironnement IT soit stable et que les contrles IT gnraux ont fonctionn durant toute la priode
daudit, quil fonctionne de manire efficace. Lors du test, lauditeur doit vrifier que le contrle test fonctionne comme
prvu dans lensemble des situations pertinentes possibles.
Test direct: le fonctionnement du contrle est vrifi sur la base dun chantillonnage ou par analyse des donnes de
transactions.
10
Grant Thornton 2007, p. 5.
11
NAS 500 lments probants de contrle, RZ 19 ss.
28
Baselining / Benchmarking: lobjectif de cette stratgie est de rduire ltendue des travaux de contrles durant les priodes
daudit suivantes. Pour ce faire, les rsultats des tests dun contrle dapplication sont repris dans les priodes de contrle
suivantes. Les tests raliss durant la premire priode daudit servent dancrage. Sil est attest quaucune modification na
t apporte au contrle dapplication dans la priode suivante et que les contrles IT gnraux pertinents ont t tests
avec succs, lefficacit des contrles dapplication est considre comme effective et ne fait pas lobjet de nouveaux tests.
A intervalles rguliers, le contrle doit toutefois faire lobjet dun nouvel ancrage. Cette stratgie de test est applicable
lorsque par ex. un contrle dapplication dpend clairement dune configuration ou si les ventuelles modifications sont
clairement visibles. La stratgie ne devrait pas tre applique lorsque le nombre de modifications apportes au systme
est lev, et ce, en raison des effets secondaires possibles et en cas de contrles IT gnraux instables.
Analyse des donnes: lefficacit dun contrle est vrifie au moyen dune analyse des donnes assiste par ordinateur.
Dans le cas idal lanalyse porte sur lensemble des donnes pertinentes.
Test de contrles contre test de transactions end-to-end
Aujourdhui, la plupart des auditeurs identifient les contrles dans le cadre du flux de transactions puis testent et valuent
leur efficacit sous forme de contrles ponctuels. Cette procdure ne correspond toutefois pas lapproche choisie gn-
ralement lors de limplmentation des applications. Lobjectif vis est de contrler les fonctionnalits de lapplication au
moyen de jeux de tests complets. Les jeux de tests sont conus pour toutes les oprations commerciales significatives et
sont raliss de bout en bout laide de lapplication. En pareilles situations, il devrait tre possible de raliser des synergies
considrables lorsque lauditeur est associ la dfinition des jeux de tests et a la possibilit de contribuer la conception
des tests couvrant non seulement la fonctionnalit oprationnelle mais galement la fonctionnalit souhaite des contrles
cls. Cette procdure peut galement constituer un ancrage pour une approche de tests ultrieure dite Baselining.
Tests de non-rgression
Par test de non-rgression, on dsigne la rptition de lensemble ou dune partie des jeux de tests afin de dtecter
dventuels effets secondaires lis aux modifications des parties dj testes dune application. Ces modifications sur-
viennent rgulirement, par exemple la suite de mises jour, de changements et de corrections logicielles. Le test de
non-rgression est une procdure de test approprie aux applications faisant frquemment lobjet de changements ou
dadaptations. Le test de non-rgression est particulirement efficace lorsquil peut tre automatis.
En relation avec lapproche de test implicite (dcrite plus haut) du contrle par des tests de bout-en-bout des transactions
commerciales, le test de non-rgression permet dattester le fonctionnement de contrles dapplication faisant lobjet de
modifications rgulires avec un cot supplmentaire faible.
29
Procdure de test, choix / taille de lchantillonnage
Les contrles par chantillonnage sont utiliss pour contrler le fonctionnement dun nombre important de contrles ma-
nuels. Le choix dun contrle par chantillonnage partir dune population de cas tester est judicieux lorsque cette popu-
lation de cas contrler satisfait au moins aux exigences particulires du PCAOB (par ex. Auditing standard n 5, AS5) ou
du IT Governance Institute. Exemple dune application du standard AS5:
Frquence ou priodicit des contrles Taille minimale des chantillons,

risque derreur
Faible Eleve
Annuel 1 1
Trimestriel (fin de priode incluse, c.--d. +1) 1+1 1+1
Mensuel 2 3
Hebdomadaire 5 8
Quotidien 15 25
Plusieurs fois par jour 25 40
Questions relatives lvaluation du fonctionnement des contrles
Les facteurs suivants peuvent influencer la procdure de contrle ainsi que le niveau dassurance obtenu par lauditeur12:
frquence de ralisation du contrle: plus la frquence de ralisation dun contrle manuel est faible, plus la quantit de
cas contrler est faible.
importance du contrle: plus lauditeur sappuie sur un contrle ponctuel pour former son opinion daudit, plus ce contrle
doit tre test.
validit du justificatif de contrle: si le contrle gnre des vidences lies lefficacit de son fonctionnement (traabilit,
exhaustivit, exactitude, horodatage), la quantit de cas tester peut tre plus faible quen cas de contrle sans justificatifs
documents.
importance relative des constats derreurs ou de diffrences. Celles-ci sont variables selon limportance, la complexit et
la quantit des transactions traites.
management Override: valuation de la probabilit de contourner ou de forcer un contrle par une personne responsable.
frquence de changement des contrles: lefficacit du contrle peut tre considrablement influence par des change-
ments touchant le contrle lui-mme ou le processus environnant
Evaluation des exceptions lors du test des contrles
Lorsque lauditeur rencontre une exception par rapport au rsultat de test attendu, il doit tablir sil sagit dun cas isol,
statistiquement prvisible, et donc acceptable. Si en revanche, aucune diffrence ntait prvisible ou si les diffrences sur-
viennent frquemment, il convient danalyser leur origine. Pour vrifier si le nombre dexceptions ne dpasse pas une limite
acceptable, il est possible, par exemple, dlargir les travaux de test du contrle par chantillonnage. Si le rsultat du test
par chantillonnage fait apparatre des contrles inoprants, des contrles compensatoires sont identifis. Si cette recherche
aboutit des contrles compensatoires inoprants, la procdure daudit doit tre adapte.
12
Ernst&Young, Evaluating Internal Controls. p. 10.
30
Influence de la taille de lentreprise
Selon la norme daudit NAS 400, lauditeur doit obtenir le mme degr dassurance indpendamment de la taille de
lentreprise; toutefois, il peut tenir compte du fait que certains contrles internes ne sont pas praticables pour de petites
entreprises ou de petites units dorganisation. Ainsi, une sparation des fonctions insuffisante (Segregation of Duties)
peut tre remplace par un contrle direct fort du management (contrle compensatoire), ou lauditeur peut compenser
labsence dvidences de contrle ou dlments probants par des contrles orients rsultat (stratgie de contrle adap-
te). La NAS 400 dfinit galement les limites du contrle interne que lauditeur doit prendre en compte lors de son va-
luation. Lauditeur qualifie le risque daudit comme lev lorsque les contrles ne peuvent viter, identifier et corriger une
anomalie importante.
Particularits
Documentation des rsultats du contrle
La description doit porter en particulier sur:

lobjet du contrle, lauditeur, la date
les contrles vrifis (version incluse), objectifs de contrle vrifis
la procdure de test utilise (contrle par chantillonnage, ensemble des cas)
le rsultat des tests, indication du type, timing (priodicit) et de ltendue des tests
les dtails suffisants pour quun tiers comptent en la matire (par ex. un autre auditeur) soit en mesure de comprendre
lefficacit des tests en termes dvaluation du risque daudit.
de plus, lauditeur doit galement dfinir les origines des exceptions, le statut de la mise en uvre des mesures
damlioration ou des informations qualitatives complmentaires.
en cas dexceptions ou de diffrences importantes, lauditeur doit fournir les informations suivantes: taille du contrle par
chantillonnage (si opportun), nombre dexceptions ou de tests chous, type et cause de lexception.
31
8 Apprciation globale
Vue densemble
Contenu et Dans ltape de conclusion, les rsultats des diffrentes tapes de laudit sont valus et synthtiss dans
objectif une apprciation globale en fonction de leur influence sur les rapports financiers.
Lauditeur met une opinion sur ladquation du systme de contrle interne et sa capacit viter des
erreurs majeures dans les tats financiers, avec un niveau dassurance raisonnable.
De plus, une apprciation globale est rendue sur:
dans quelle mesure lapplication contrle supporte le processus mtier (conception des contrles,
fonctionnement des contrles)
la prsence de lacunes de contrle significatives dans lapplication
limpact des lacunes de contrle sur les traitements de lapplication et sur le processus global ainsi que
sur les assertions sy rapportant dans les tats financiers
la prsence, dans le processus mtier, de contrles qui compensent limpact dventuelles faiblesses
de contrle dans lapplication et sur les vrifications de contrle et les procdures daudit orientes
rsultat supplmentaires ncessaires.
Contexte Lorsque les faiblesses des contrles applicatifs peuvent influencer significativement lexactitude de
lopinion sur les tats financiers, et que ce risque ne peut pas tre compens par dautres contrles (p.
ex. des contrles manuels dtectifs), limpact de ces faiblesses sur le rapport annuel doit tre valu.
Cette valuation se fait partir des trois points de vue suivants:
1. sagit-il dun fait qui affecte ltat financier?
2. sagit-il dune violation de la loi ou des statuts?
3. sagit-il dun lment qui affecte lopinion daudit? Lors de lvaluation de limpact sur lopinion daudit,
lauditeur value la possibilit de couvrir limpact possible des contrles inoprants par des procdures
daudit substantives.
Les indicateurs de contrles applicatifs inoprants peuvent tre notamment: le contournement (override)
ou la dsactivation (disable) de contrles, lutilisation errone dinformations gnres par ordinateur, des
donnes de base et de pilotage errones, des contrles IT gnraux inoprants, des lments probants de
contrles manquants, une prdominance arbitraire de contrles uniquement dtectifs ou prventifs.
Les rflexions auxquelles lauditeur doit se prter lors de lvaluation des contrles sont dfinies dans la
norme NAS 700.
Procdure
Rsultats
Les rsultats individuels des procdures daudit ralises jusquici sont compils. Pour les contrles manquants ou mal
conus ainsi que les contrles qui nont pas fonctionns de manire effective pendant la priode daudit, limpact sur les
rapports financiers doit tre valu. Les assertions dans les comptes annuels constituent le lien entre lapplication et les
rapports financiers. Elles formulent les objectifs poss aux positions des comptes annuels et doivent tre contrles afin de
savoir si des lacunes dans les contrles pourraient, avec une certaine probabilit, avoir un impact ngatif sur la ralisation
des objectifs.
Malgr les moyens auxiliaires existants et utiliss (frameworks, listes de contrle, etc.), les conclusions des travaux nces-
sitent le recours au jugement professionnel de lauditeur pour tenir compte des particularits de lentreprise, des exigences
lies aux processus et celles spcifiques aux risques. Cela exige une discussion approfondie au sein de lquipe de rvision
afin de dfinir les procdures daudit supplmentaires.
32
Lauditeur tablit lintention de la direction, outre son opinion daudit, une synthse de la situation des risques au niveau
des processus et des applications contrls.
Particularits
Les exceptions identifies lors de lvaluation des contrles cls et non corriges par des contrles compensatoires doivent
tre values, par dfinition, de manire plus critique que les dficiences des autres contrles.
33
Annexe 1 - Contrles lis aux applications
Une entreprise doit implmenter les mesures ncessaires pour garantir la scurit et la conformit des applications et donc
des processus mtiers. Chaque processus daffaire, sous-processus ou activit doit donc tre pilot dune manire ou dune
autre pour atteindre les objectifs dfinis. On parle ici du terme contrles, qui dsigne tous les concepts, procdures,
pratiques et structures dorganisation permettant de vrifier avec une assurance raisonnable la ralisation des objectifs
dentreprise et la prvention ou lidentification et la correction dvnements non dsirables.
Le terme contrle vient de langlais control et signifie entre autres commande, dispositif pour manuvrer, mais gale-
ment matrise, supervision, pilotage ou guidage, ce qui dpasse de loin le sens habituel et plutt limit que lon donne au
terme contrle.
Chaque application et donc chaque processus commercial spcifique contient des contrles qui garantissent la ralisation
des objectifs dfinis. Ces contrles sont appels contrles applicatifs. Il sagit par exemple de contrles dexhaustivit,
dexactitude, de validit et de sparation de fonction. Outre les contrles lis aux applications, il existe des contrles non
lis aux applications, appels galement contrles IT gnraux. Il sagit par exemple de contrles dans le domaine des d-
veloppements de systme, des modifications, de la scurit et de lexploitation. Ces contrles ne sont pas traits dans ce
chapitre.
Il est vident que chaque type dapplication exige des contrles diffrents: chaque activit commerciale spcifique comporte
des risques commerciaux diffrents, inhrents cette activit et susceptibles dempcher latteinte des objectifs.
Exigences suprieurs et contrles lis aux applications
Les contrles applicatifs ont pour but dassurer un traitement conforme et sr des transactions et de fournir la preuve de
lexactitude des rsultats. Par consquent, les contrles jouent un rle central dans la ralisation des objectifs dentreprise,
de la protection du patrimoine, de lexactitude et de la fiabilit de la comptabilit et du respect de la politique commer-
ciale.
Avec les contrles applicatifs, lentreprise garantit la saisie exhaustive, exacte, valide et vrifiable de toutes les transactions
commerciales significatives des processus mtier ainsi que le traitement, lenregistrement et ldition de ces derniers par le
systme. Lobjet des contrles lis aux applications est donc avant tout la saisie, lenregistrement, le traitement et ldition
de transactions et de donnes. Les contrles lis aux applications stendent sur lensemble du processus commercial.
Types de contrles lis aux applications
On distingue les types de contrles applicatifs suivants:

1 Cration et autorisation
2 Saisie et enregistrement des donnes
3 Traitement des donnes
4 Sortie des donnes (Output)
5 Interfaces
34
1 Cration et autorisation
Les principaux objectifs relatifs la cration et lautorisation sont les suivants:

minimiser les erreurs et les omissions
identifier, documenter, communiquer et corriger les erreurs et les irrgularits ds leur apparition
vrifier lexactitude de la correction des erreurs par un service / une personne indpendante
les oprations commerciales (transactions) ne sont effectues que par des personnes habilites et / ou selon des procdures
autorises
les personnes responsables de la saisie des transactions commerciales sont identifies dans le systme
les justificatifs de saisie dlivrs sont exhaustifs et exacts et sont transmis en temps utile
les justificatifs de saisie sont conservs pendant la priode lgale et sous la forme prescrite ou peuvent tre reconstitus
par lorganisation.
Les contrles typiques concernant la cration et lautorisation sont les suivants:

profils des comptences pour ltablissement de pices comptables (par ex. rglement sur les signatures) et mise en uvre
au travers un contrle des autorisations par des systmes de gestion des accs
sparation des fonctions de cration et de validation de pices comptables
visa ou signature sur les justificatifs de saisie
formulaires de saisie comprhensibles et utiles (par ex. avec des champs primprims)
processus didentification prcoce et de traitement des erreurs et des irrgularits
collecte systmatique des pices comptables (par ex. dans lordre chronologique laide dun horodateur ou squentielle-
ment laide dun systme de numrotation continue)
micro filmage ou numrisation des justificatifs et conservation sur un support permettant de reconstruire les informations
originales dans les dlais requis.
2 Saisie et enregistrement des donnes
Les principaux objectifs de la saisie et de lenregistrement des donnes sont les suivants:
seules des personnes habilites (ou les processus autoriss) peuvent enregistrer des donnes
lexactitude, lexhaustivit et la validit des champs importants (par ex. numros de compte, montants, code article) sont
contrles dans les crans ou programmes en amont du processus de saisie
les erreurs et les anomalies de saisie / denregistrement sont identifies, documentes, communiques et corriges en
temps utile
lexactitude de la correction des erreurs est vrifie par un service / une personne indpendante
Les contrles typiques de saisie et denregistrement des donnes sont les suivants:
profils des comptences pour la saisie / enregistrement des transactions et mise en uvre au travers dun contrle des
autorisations par des systmes de gestion des accs
masques de saisie comprhensibles et conviviaux avec des contrles de format de donnes intgrs (par ex. champs de
date, donnes numriques, champs obligatoires, etc. et liste de valeurs prdfinies et rcurrentes)
contrle automatique approfondi des valeurs saisies (par ex. dpassements de valeurs limites, contrle de plausibilit des
contenus, synchronisation avec les donnes enregistres)
affichage des libells de code complets aprs saisie du code (par ex. la dsignation dun article saffiche la saisie du
numro darticle)
35
comparaison des donnes saisies, cest--dire comparaison des donnes saisir avec les donnes visibles lcran ou avec
des journaux de saisie (compte tenu du cot, judicieux uniquement pour les transactions critiques telles que les mutations
de donnes de base notamment)
totaux de contrle par lots: nombre de documents (ex nombre de factures), somme de zones de valeurs figurant sur les
documents ou sommes numriques (montants, quantits), somme de contrle (condensat, hash, addition mathmatique
de numros de documents, numros de compte)
contrle de lordre dapparition des pices comptables numrots en continue au sein dun lot pour identifier les numros
manquants ou les doublons de saisies
comparaison des donnes saisies avec les valeurs enregistres (par ex. postes ouverts avec des oprations comptables
nouvellement cres)
saisie de contrle (appele galement double saisie, contrle des 4 yeux); saisie double de valeurs importantes par
diffrentes personnes (gr par le systme de gestion des accs) ou le cas chant, par une seule et mme personne (par
ex. lors de la saisie masque dun nouveau mot de passe)
contrle visuel des valeurs saisies gnralement par une deuxime personne; convient pour les cas critiques et un petit
nombre de transactions
processus didentification prcoce et de traitement derreurs et danomalies, les transactions corriges devant tre nou-
veaux entirement vrifies
3 Traitement des donnes
Les principaux objectifs du traitement des donnes sont les suivants:

lexhaustivit, lexactitude et la validit des traitements raliss sont vrifies selon une procdure de routine; les erreurs
de traitement sont identifies au plus tt, documentes et corriges en temps utile
la correction de transactions errones se droule sans entraver inutilement le traitement des autres transactions
les calculs, totalisations, consolidations, analyses et affectations sont effectus correctement par le programme
la sparation des fonctions est assure y compris pendant le traitement des donnes
les transactions gnres automatiquement par lapplication (par ex. intrts sur crdit priodiques, commandes en cas
de dpassement du seuil de scurit des stocks) font lobjet des mmes contrles dexhaustivit, dexactitude et de validit
que les transactions isoles
les dcisions importantes reposant sur des calculs automatiques sont prises et vrifies par des personnes
Les contrles typiques du traitement des donnes sont les suivants:
un grand nombre des contrles dcrits prcdemment pour la saisie et la cration de donnes peuvent tre appliqus pour
le traitement (par ex. comparaison des champs individuels, totaux de contrle par lots, contrle de lordre dapparition et
comparaison de donnes, synchronisation automatique du grand livre et des livres auxiliaires). Il est cependant important
que les documents et les totaux utiliss pour les contrles correspondent aux rsultats de fin de traitement
rapprochement des donnes traites dans le systme avec des confirmations externes (par ex. inventaires, confirmations
de soldes bancaires et de soldes de comptes)
garantie de lintgrit du traitement grce aux quatre objectifs de processus suprieurs: atomicit (unit de travail non
divisible, toutes les actions sy rapportant sont effectues avec succs ou aucune dentre elles ne lest), consistance (lorsque
la transaction natteint aucun statut final stable, elle doit tre rinitialise dans le systme ), isolation (le comportement
dune transaction nest pas influenc par dautres transactions effectues simultanment) et durabilit ( lissue dune
transaction, ses consquences restent durables, y compris les changements en cas de pannes de systme). Ces contrles
sont souvent implments hors des applications (par ex. dans des systmes de base de donnes). Ceci doit toutefois tre
vrifi au cas par cas.
36
4 Sortie de donnes (output)
Les principaux objectifs de la sortie des donnes sont les suivants:

la sortie des donnes seffectue en temps utile, au bon endroit et conformment aux procdures dfinies
lexhaustivit et lexactitude des informations dites sont garanties par des procdures effectues de manire systma-
tique sur des totaux de contrle et un rapprochement avec les totaux de contrle correspondant du traitement
le traitement, la conservation et la destruction doutput sont conformes aux exigences de la protection des donnes et
de scurit (avant et aprs leur diffusion auprs des utilisateurs)
les informations imprimes sont conserves conformment aux dispositions lgales.
Les contrles typiques de la sortie des donnes sont les suivants:

les contrles denvoi et de rception rglent les modalits de communication des listes et autres outputs (qui, quand, quoi,
comment et en combien dexemplaires)
les systmes de gestion des accs garantissent la traabilit des accs des utilisateurs lors de consultations lcran ou de
commandes de listes en ligne
les contrles de numrotation et dexhaustivit garantissent que la gestion, ldition, la restitution, la rception et la
destruction (par ex. en cas de copie de contrle) doutputs critiques (par ex. chques, bons, obligations de caisse, etc.)
seffectuent conformment aux procdures
lexactitude et lexhaustivit des impressions priodiques (par ex. traitement semestriel et annuel) sont contrles au
moyen des contrles par chantillonnage.
5 Les interfaces
Les principaux objectifs relatifs aux interfaces sont les suivants:

lauthenticit et lintgrit des informations provenant de sources externes lorganisation sont contrles soigneusement
avant dentreprendre toute action potentiellement critique, indpendamment du moyen de rception (tlphone, voice-
mail, papier, fax, e-mail, ou fichier)
les informations sensibles sont protges pendant leur transmission par des mesures appropries contre les accs non
autoriss, les modifications ou les adressages errones
Les contrles typiques au niveau des interfaces sont les suivants:

un grand nombre des contrles prsents prcdemment pour la saisie et lenregistrement des donnes peuvent gale-
ment tre utiliss pour le contrle des interfaces (par ex. comparaison des positions individuelles, totaux de contrle de
lots, contrle de numrotation et comparaison de donnes).
authentification de chaque message laide de procdures cryptographiques
cryptage de chaque message (important) pour garantir
- la confidentialit du contenu
- lintgrit du contenu du message
- lidentit de lexpditeur.
Remarque: un grand nombre des contrles raliss au niveau des interfaces concernent principalement le transport et la
transmission ainsi que lenregistrement lectronique des donnes; il sagit en gnral de contrles non lis une applica-
tion. Ces derniers ne seront pas dtaills dans ce document.
37
Annexe 2 Glossaire
Applications
On distingue:
Les applications standard: les applications standard sont souvent des logiciels, utiliss ou vendus, qui ont t dvelopps
pour un nombre important dentreprises et gnralement vendus plusieurs fois. Les applications standard typiques sont par
exemple des logiciels mtiers spcifiques des secteurs dactivit, des logiciels multifonctions tels que les logiciels bureau-
tiques, la gestion de workflow, la gestion de documents ou des logiciels spcialiss tels que les systmes de gestion intgre
ERP, CAD, les logiciels de distribution, les systmes de gestion de marchandises et des inventaires, de comptabilit ou de
gestion des ressources humaines. Lavantage dune application standard du point de vue du contrle interne (SCI) est quun
grand nombre de dveloppeurs et de clients travaillent sur lapplication et donc contribuent son amlioration permanente
(conception, dveloppement, test et documentation).
Une application ddie est gnralement dveloppe sur mesure pour une entreprise donne ou pour rpondre un besoin
spcifique (en interne ou des entreprises tierces). En comparaison avec les applications standards, le logiciel ddi prsente
souvent plusieurs problmes (ex. dveloppeurs moins qualifis, logiciels et matriels ne rpondant pas aux exigences du
moment, solutions inabouties, implication inadquate du mandant dans le dveloppement, etc.).
Application Service Provider (ASP)

Le service dApplication Service Providerconsiste mettre la disposition dun client une application exploite par un
fournisseur de services dapplication (par ex. un systme ERP) au travers dun rseau public ou priv. Le logiciel nest pas
achet, mais seulement lou en cas de besoin. LASP se charge de toute ladministration, de la scurit des donnes, de la
maintenance applicative etc. A la diffrence de lhbergement dapplication pur, lASP fournit galement des services (par
ex. gestion des utilisateurs) autour de lapplication.
Assertions (dans les tats financiers)

Assertions explicites ou implicites de la direction retenues pour la prparation des tats financiers. Elles peuvent tre classes
de la manire suivante:
Existence: un actif ou une dette existe vritablement la date de la clture;
Droits et obligations: un actif ou une dette peut tre attribu lentreprise la date de clture;
Evnement: une transaction ou un (autre) vnement est survenu durant la priode et est attribuable lentreprise;
Exhaustivit: il nexiste pas dactif, de dette, de transaction ou dautres vnements non recenss ou de postes non pu-
blis;
Apprciation: une dette figure au bilan avec une valeur approprie;
Saisie et dlimitation de priode: une transaction ou un vnement (quelconque) est saisi avec le montant correct et affec-
t la priode correcte et prsentation et publication: un poste est publi, class et formul conformment aux normes
comptables applicables.
Baselining/Benchmarking pour les contrles applicatifs

Stratgie de contrle dans laquelle les rsultats des tests des contrles applicatifs sont repris dans les priodes de contrle
suivantes: les contrles applicatifs sont tests durant la premire priode de contrle, la priode dite baseline. A condition
de prouver quaucune modification na t apporte au contrle applicatif dans la priode suivante et que les contrles IT
gnraux pertinents ont t tests et sont efficaces, lvaluation des contrles applicatifs est considre comme effective et
ne fait pas lobjet de nouveaux tests. Lobjectif de cette stratgie de contrle est de rduire ltendue des contrles orients
rsultat durant les priodes de contrle suivantes.
38
Benchmarking: voir Baselining
Business Rule
Terme technique dsignant les rgles de gestion devant tre prises en compte dans les spcifications de lapplication, son
dveloppement, les tests et la livraison compte tenu de limpact important quelles peuvent avoir, en tant quexigences de
contrles cl, sur la conception du SCI.
Caractre significatif
Des informations ont un caractre significatif lorsque leur omission ou leur prsentation errone pourrait influencer des
dcisions conomiques des destinataires prises sur la base des tats financiers. Le caractre significatif dpend de la taille
du poste ou de lerreur rsultant de circonstances particulires de lomission ou de la prsentation errone. Le caractre
significatif est plutt un seuil ou une valeur limite et moins une exigence qualitative premire que doit avoir une information
pour pouvoir tre utile.
Contrles
Les contrles sont des concepts, des procdures, des pratiques et des structures dorganisation permettant de vrifier
avec une assurance raisonnable la ralisation des objectifs dentreprise et la prvention ou lidentification et la correction
dvnements non dsirables.
On distingue entre autres:
Contrles applicatifs
Les contrles applicatifs sont des contrles intgrs aux applications. Les objectifs des contrles applicatifs portent sur des
applications spcifiques. Les contrles typiques portent sur lexhaustivit et lexactitude des saisies et des traitements, sur
la validit des saisies, etc.
Contrles IT gnraux
Les contrles IT gnraux constituent la base pour un fonctionnement en bonne et due forme des contrles applicatifs
automatiss. Les contrles IT gnraux couvrent les risques inhrents aux droits daccs, la qualit et la scurit des
donnes ou la maintenance et aux changements des systmes (matriel et logiciel).

Contrles hybrides
Combinaison de contrles manuels et automatiques

Contrles compensatoires
Contrles internes qui rduisent le risque dune faiblesse existante ou potentielle susceptible doccasionner une erreur ou
une omission.
Direction de lentreprise
Personnes responsables de la surveillance, de la haute direction et du contrle (Gouvernance) dune entreprise (par ex. le
conseil dadministration dune SA). Cette notion est utilise dans les cas o lon ne peut pas faire la distinction entre, dune
part, les responsables de la gestion et du contrle et, dautre part, la direction des affaires.
39
Direction et surveillance
Personnes qui sont responsables de la surveillance, de la haute direction et du contrle (Gouvernance) dune entreprise
(par ex. le conseil dadministration dune SA). Les membres de la direction ne font partie de ce cercle que lorsquils assument
les fonctions prcites.
Donnes
On distingue:
Donnes de base: donnes statiques servant lidentification, la classification et la description, souvent utilises par
plusieurs applications et qui prsentent un caractre relativement permanent. Les donnes de base sont donc des donnes
qui ne changent pas pendant une longue priode (paramtres, donnes sur les clients et produits).
Donnes de flux (ou transactionnelles): donnes prsentant une certaine dynamique avec un caractre temporel (par ex-
emple assorties dune date de validit). Les donnes transactionnelles sont sans cesse renouveles par les processus op-
rationnels de lentreprise et sont gnralement utilises par une seule application ou par un petit nombre dapplications.
Remarque: la classification dans lune ou lautre catgorie nest pas toujours vidente et dpend fortement du contexte. Les
donnes de base dans une application ou une base de donnes (par ex. donnes sur les articles dans un systme de gestion
des stocks) peuvent tre des donnes transactionnelles dans une autre base de donnes (par ex. donnes sur les articles
dans une application servant la cration dun catalogue de produits centralis au sein dun mme groupe).
Elments probants
Informations dont lauditeur tire des conclusions et sur lesquelles repose son opinion daudit. Elles comprennent des do-
cuments et enregistrements comptables comme base des tats financiers ainsi que des informations dautres sources les
corroborant.
Environnement de contrle
Attitude gnrale, prise de conscience et action de la direction de lentreprise en relation avec le contrle interne et sa
signification pour lentreprise. Influence lefficacit des contrles internes individuels.
ERP
ERP signifie Enterprise Resource Planning. Lobjectif des systmes ERP est dintgrer de bout en bout lensemble des
processus mtier dans un systme centralis. Les domaines dutilisation typiques des logiciels ERP sont la finance et la
comptabilit, la gestion du matriel, la production, la vente, le marketing, etc. ainsi que la gestion des donnes de base y
relatives. La capacit de paramtrisation des systmes ERP standards, permet dans la pratique dadapter les caractristiques
de fonctionnement aux exigences de chaque entreprise.
Examen succinct : voir Review / Examen succinct
Interfaces
Une interface est un lment de systme servant la communication, lchange dinformations entre diffrents compo-
sants et sous-systmes. Une interface est dfinie par un nombre de rgles.
Dans le cas dinterfaces de donnes, lchange a lieu sous forme de donnes logiques, par ex. via des fichiers ou des
enregistrements de donnes.
40
Les interfaces entres logiciels (interfaces externes) et les points dintgration entre diffrents modules (interfaces internes)
sont des points de contact logiques dans un systme informatique. Elles dfinissent les modalits dchange des com-
mandes et des donnes entre les diffrents processus et composants du systme (par ex. accs aux routines systme, autres
processus, composantes logicielles, etc.).
Objectif de contrle
Un objectif de contrle est une expression du rsultat souhait (but) devant tre atteint grce la mise en place de (proc-
dures de) contrles dans un domaine dactivit.
Paramtre
Par paramtre, on entend en informatique un argument transmis un programme ou un sous-programme (donne de
pilotage externe).
Patch (correctif)
Un patch est un correctif pour un logiciel ou pour des donnes du point de vue de lutilisateur final destin corriger des
failles de scurit ou installer de nouvelles fonctionnalits. Souvent, un patch constitue une solution temporaire en at-
tendant que le problme soit rgl. Comme les patches ne sont pas soumis des procdures de test aussi rigoureuses que
celles des programmes proprement parler, ils peuvent tre lorigine de nouvelles dficiences et problmes de scurit
dans les applications.
Principes gnraux de laudit ou des services connexes; gnraux

Principes rgissant lexercice responsable de la profession dauditeur ou dexpert-comptable:
Indpendance (dans le cas dun audit ou dune review);
Intgrit;
Objectivit;
Comptence professionnelle et diligence;
Discrtion;
Comportement professionnel;
Respect des prescriptions et des normes lgales.
Procdures analytiques: voir Procdures daudit; analytiques
Procdures daudit; analytiques

Procdures visant obtenir des lments probants (souvent analyses de donnes assistes par un outil informatique). Ces
procdures sont utilises dans le cadre des analyses de tendances et de chiffres cls mais galement lors de lexamen des
modifications et des relations qui diffrent dautres informations pertinentes ou de montants faisant lobjet de prvisions.
Procdures daudit; orientes rsultat

Procdures daudit permettant dobtenir des lments probants pour identifier des anomalies significatives dans les tats
financiers. Il convient de distinguer entre les procdures de vrification de dtail et de vrification analytiques. Synonyme:
procdures daudit substantives.
Procdures daudit; orientes procdures ou risques

Procdures daudit permettant dobtenir des lments probants sur ladquation de la conception et de lefficacit du fon-
ctionnement du systme comptable et des contrles internes.
41
Rapport de gestion
Document tabli chaque anne et comportant les tats financiers audits ainsi que le rapport de lauditeur (et, le cas
chant, dautres informations). Juridiquement, le rapport de lorgane de rvision ou du rviseur des comptes consolids
ne fait pas partie du rapport de gestion.
Release
La version aboutie et publie dun logiciel est appele release. Toutes les modifications dune release une autre sont habi-
tuellement saisies systmatiquement dans loutil de gestion de version ou de configuration dates (horodatage) et assorties
de la rfrence utilisateur. Il est important que tous les utilisateurs utilisent la mme version de logiciel et que lauditeur
puisse identifier tout changement de release.
Reproductibilit
Les informations traites dans un systme dinformation et les oprations effectues par le systme sont rtroactivement
contrlables et vrifiables.
Review / Examen succinct

Le but dun examen succinct (Review) des tats financiers consiste indiquer si lauditeur a rencontr des lments le con-
traignant conclure que les tats financiers ne concordent pas, tous les gards importants, avec les normes de prsen-
tation des comptes applicables. Lauditeur fait cette assertion sur la base de procdures daudit qui ne livrent pas tous les
lments probants exigs par un audit (lments probants). La review dinformations financires ou dautres informations
labores selon des critres appropris poursuit un objectif comparable.
Rotation
Par principe de rotation, on entend habituellement le principe daudit qui consiste ne pas vrifier chaque anne lensemble
des contrles cls mais procder, sur la base du jugement de lauditeur, un minimum de vrifications de contrles cls
au cours dune anne et dans certains domaines. Il faut toutefois sassurer que lensemble des contrles cls sont pris en
compte dans laudit au cours dun cycle de planification dfini par lauditeur en fonction de la situation des risques (gn-
ralement 3 ans).
SaaS: voir Software as a Service.
SAS 70
Statement on Auditing Standards (SAS) No. 70, Service Organizations, est une norme daudit reconnue internationalement
et dveloppe par le American Institute of Certified Public Accountants (AICPA). SAS 70 est une norme permettant aux or-
ganisations de services de prsenter leurs activits et leur processus de contrles leurs clients et aux auditeurs dans un for-
mat de rapport standardis. Elle permet aux organisations de services, lorsquelles hbergent ou traitent des donnes et des
processus oprationnels de clients, de prouver quelles ont implment des contrles et des mesures de scurit adapts.
Software as a Service (SaaS)

Mthode de mise disposition dun logiciel ( la demande) via Internet. Semblable Application Service Provider (ASP). Par
rapport au modle ASP, SaaS est davantage conu pour lintgration dautres procdures / applications et peut ainsi mieux
supporter une architecture oriente service (SOA).
Sondage: voir Test de cheminement
42
Systme de contrle; interne

Dfinition selon la norme daudit NAS 890: Le SCI au sens de la nouvelle norme daudit comprend uniquement les processus
et les mesures dans une entreprise qui garantissent une tenue rgulire de la comptabilit et des rapports financiers. Le
SCI est constitu, selon la dfinition communment admise, de composantes de contrle (environnement de contrle,
processus dvaluation des risques de lentreprise, systmes dinformation / de communication importants pour la tenue de
la comptabilit et ltablissement des comptes) dactivits de contrle et de surveillance des contrles. Dans des situations
simples, ces composantes de contrle prsentent souvent des caractristiques diffrencies ou peuvent galement tre
regroupes.
Dfinition au sens large: ensemble des principes et des procdures (contrles internes) dfinis par la direction en vue de
garantir la conformit et lefficacit des traitements oprationnels (incluant les prises en compte des principes dfinis par
la direction de lentreprise), la scurit des actifs, la prvention ou lidentification de fraudes et derreurs, lexactitude et
lexhaustivit des enregistrements comptables ainsi que llaboration dinformations financires fiables et utilisables, en
temps utile.
Test de cheminement
Un test de cheminement dsigne lanalyse systmatique (reconstruction) dun processus et sert comprendre et vrifier
ce dernier. Lors de cette vrification, lauditeur suit les chemins travers le processus dfinis par les conditions pralables et,
le cas chant, par les dcisions prises par lutilisateur.
Test de non-rgression
Rptition dun test qui a dj t entirement ralis, par ex. dans le cadre de travaux dentretien, de modification et de
correction, le test de non-rgression permet de faciliter lanalyse des rsultats du test par comparaison avec les rsultats du
test prcdant.
43
44

Guide Audit Applications PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guide Audit Applications PDF

Transféré par

Droits d'auteur :

Formats disponibles

Guide daudit des applications

Guide daudit des

Graphiques et mise en page: Felice Lutz, ITACS Training AG

Table des matires

Table des matires 3

Prsentation gnrale et introduction 4

Analyse du bilan et du compte de rsultats 7

Identification des processus mtier et des flux de traitement des donnes 9

Identification des applications de base et des principales interfaces IT pertinentes 13

Identification des risques et des contrles cls 18

Evaluation de la conception des contrles 24

Evaluation du fonctionnement des contrles 28

Annexe 1 - Contrles lis aux applications 36

Etendue et dlimitation La mthode prsente se limite la procdure de contrle des applications IT au

Lutilisation de lapproche nest pas limite laudit des critres rglementaires; la

Les 8 tapes de la mthode de vrification:

Chacune des quatre couches reprsente un type de processus et de ressource.

1 Analyse du bilan et du compte de rsultats

RISQUE Assertions dans les

Identification des transactions et des classes de transactions significatives

2 Identification des processus mtier

Identification des processus significatifs

Utilisation de la documentation existante

Cration dune nouvelle documentation formes de reprsentation

Position de bilan ou du Montant en milliers Rsultat (Output) Processus Entre (Input)

Prsentation sous forme de graphique (forme de flux de traitement) - solution adapte

Stratgie Organisation dentreprise Gestion du personnel

Category Management (CM)

Communication Gestion de la qualit Gestion immobilire

Gestion des emplacements Services internes Production

Gestion des paramtres et des donnes de base

3 Identification des applications de base

Contenu et Identification des applications IT concernes et de leurs interfaces

Elaboration dune cartographie des applications

Inventaire et catgorisation des applications pertinentes du point de vue financier

Contrle de la validit du mot de passe

Historique des tentatives de connexion choues

Interdiction de supprimer Le programme ne doit pas proposer de fonction de suppression des

En outre, les contrles numrs ci-dessous sont galement trs importants:

Applications standard fortement adaptes

Exploitation de lapplication par des tiers ou au sein de lentreprise

Utilisation centralise ou dcentralise de lapplication

Reprsentation des informations

Reprsentation sous forme de tableau

Position Montant Processus Application Commentaire / pr- Type Exploitation Utilisation

CA 675123 Facturation SAP FI Interfaces FACTURE Standard Int. Centralise

Inventaire des principales interfaces

Nom de Type Applications en Type de flux Frquence Listes derreur Evaluation

Risques, objectifs de contrle et contrles

se pas- Le contrle Les con- Oui / non

Autorisation capable de ils raliss?

Exhaustivit des risques et des contrles

Concentration sur les contrles cls

Documentation des contrles dapplication

Le tableau ci-dessous prsente deux exemples:

Description 3-Way Match Sparation des fonctions

Contexte Le test de cheminement permet de vrifier systmatiquement:

Questions devant tre prises en compte durant le test de cheminement du processus:

Prsentation des informations

Evaluation de la conception des contrles

PS 400: Evaluation des risques et contrle interne RZ27.

Questions relatives lvaluation de la conception des contrles

Menzies 2006, p 271 et s.