Guide Audit Applications

Guide daudit des applications informatiques
Une approche inspire des audits financiers

Novembre 2008
Proc
essu
s m
tier
App
licat
ions
Syst
me
s IT
Infr
ITA
astr
uctu
re IT
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
Cet ouvrage est le fruit des rflexions et des expriences des membres de la Commission informatique de la Chambre fiduciaire 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 Prsentation gnrale et introduction Analyse du bilan et du compte de rsultats Identification des processus mtier et des flux de traitement des donnes Identification des applications de base et des principales interfaces IT pertinentes Identification des risques et des contrles cls Tests de cheminement Evaluation de la conception des contrles Evaluation du fonctionnement des contrles Apprciation globale Annexe 1 - Contrles lis aux applications Annexe 2 - Glossaire 3 4 7 9 13 18 22 24 28 32 36 38
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 domaines 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 processus, une mthode de vrification et une approche intgre de laudit des contrles 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 financiers. 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 dvelopp 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.
Les 8 tapes de la mthode de vrification: Il est judicieux danalyser les tats financiers afin dorienter
om du c pte
les procdures daudit des processus de lentreprise et des applications correspondantes sur les tests des comptes financiers significatifs et sur les risques daudit sy rapportant.
els
et ilan ts du b ta lyse e rsul d Ana
Id
at opr ssus roce nes s p don n de catio t ux de nti e e app des ces a tion ica et interf ent ion licat
ionn
Cette analyse lie les principales positions comptables aux processus mtiers pertinents ou, plus concrtement, dtermine les flux de traitement des donnes lorigine des principales positions comptables et des applications de base qui supportent ces flux de traitement des donnes. Une fois les applications de base identifies, lauditeur
s cl
Id
s ri n de catio les cls ti Iden t contr e hem de c inem
s sque
sintresse la qualit du systme de contrle. Il dtermine dabord si la conception du systme de contrle est adapte la situation de risque actuelle des processus de lentreprise et enfin si les contrles prvus sont implments et sont efficaces.
ent
Test
ua Eval
tion
de
nce la co
du tion
cont
rle
Lvaluation du systme de contrle des processus mtiers pris en compte dans le cadre de laudit permet lauditeur de savoir sil peut sappuyer sur les procdures de production des tats financiers et, le cas chant, de dfinir ltendue des procdures daudit substantives supplmentaires quil doit effectuer.
on uati Eval
du
tion fonc
nem
ent
ont du c
rle
A
8
ciati ppr
on g
loba
le
La prsente mthode ne traite pas, de manire explicite, les contrles IT gnraux. Lauditeur doit valuer et tester systmatiquement 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 simplifie ci-aprs. Dans la ralit, les interactions peuvent tre beaucoup plus complexes, la schmatisation permet simplement de comprendre lapproche de contrle.
Dlimitation de lapproche de contrle
couvert par la mthode
Pro
us cess
mt
ier /
tra
tio nsac
ns
Contrles IT gnraux Environnement de contrle IT (polices, directives) Dveloppement de programmes Modications IT Exploitation IT Gestion des accs Scurit des systmes Scurit des donnes
App
li
ons cati
na
nci
res
Contrles dapplications IT Intgralit Exactitude Validit Autorisation Sparation des fonctions
non couvert par la mthode
Mid
dle
ase e/b war
de d
onn
es
Syst
sd me
ita xplo
tion
/ rs
eau
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.
1 Analyse du bilan et du compte de rsultats

Vue densemble
Contenu et objectif Nous considrons que lobjectif de contrle est la conformit de la tenue de la comptabilit. La procdure 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. 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 importantes 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.
Contexte
Procdure
Principaux comptes
par ex. dbiteurs RISQUE RISQUE
Assertions dans les tats nanciers, par ex.: Authenticit
RISQUE
mt ier
valuation Intgralit Droits et obligations
RISQUE
Pro
us cess
App
licat
ions
Syst
s IT me
ACS IT
in Train
Infr
astr
re IT uctu
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. Manuel suisse daudit, 1998, chapitre 3.2424 Analyse des comptes annuels
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 procdures 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 oprations 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 commerciales 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 frquemment 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
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.
2 Identification des processus mtier et des flux de traitement des donnes

Vue densemble
Contenu et objectif Identification des processus mtiers significatifs qui sont lorigine des transactions et classes de transactions 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. 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, limits 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.
Contexte
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 graphique. 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 documentation 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.
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..
Prsentation sous forme de tableau. solution adapte des lments comptables et interactions simples. Position de bilan ou du compte de rsultats Chiffre daffaires Montant en milliers de CHF 675123 Rsultat (Output) Factures Processus Vente Entre (Input) Contrats, services fournis Commandes
Cots Inventaire Equipements Crditeurs Frais de personnel Assurances Immobilisation Divers
422234 57000 121000 45000 121111 13000 121000
Paiements
Achat
Paiements
Gestion ressources humaines Etc Bouclement Consolidation
Contrats, services Valeur Positions dune filiale
Amortissement Positions consolides
Prsentation sous forme de graphique (forme de flux de traitement) - solution adapte des interactions complexes Exemple A
Sal ials ter eMaanag t m men n d ctio g n du ishe erin ine Pro Fin ductio Eng pro ork ng
MR P
es
ic teg Stra ales s
tive era Op sales
cha Pur ing s gic
g te Stra hasin purc
W duli ials e sch ter eMaanag t m men Rawrials te ma MR ting g era in Op rchas pu P
pre
Job ation par Sh reh Wa ous e in opp g
Cu
sto
r me
Pro re Wa ods Go cept re d Ven or hou se
duc
tion
Billi ory g ent Inv ountin acc l r na g Inte untin o acc
ng
ts oun le Acc eivab rec
ory g ent Inv ountin acc e n oic Inv catio ti ver a
GL nting u cco
Acc
ou
nti
ng ng
Co
t cos t n ad rhe eme Ove anag m
olli ntr
ets g Ass untin o acc ts oun Accayable p
10
Exemple B
Processus de pilotage Corporate Governance Stratgie Processus de dnition des objectifs Organisation dentreprise Category Management (CM) Acquisition (achat/dispatching) March Logistique Vente Processus de support Finances/Services Communication Gestion des emplacements Informatique Gestion de la qualit Services internes Personnel/formation Gestion immobilire Production March Contrle de gestion Gestion du personnel
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 fournisseurs et comptabilisation des achats. Le processus de vente est compos des sous-processus gestion des donnes de base clients, facturation clients et comptabilisation 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 paramtres 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 objectif Identification des applications IT concernes et de leurs interfaces
essu Proc
s m
tier
App
ion licat
Syst
me
s IT
u astr Infr
ITA
e IT ctur
CS
Tr ai n
in
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 impossibilit 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 programme 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 standard devrait disposer des fonctionnalits suivantes (liste non exhaustive) Datation automatique des opration et des transactions par le systme Offrir plusieurs identifications utilisateurs avec des mcanismes dauthentification Ces fonctionnalits offrent (ou impliquent) les contrles suivants
Protection de laccs aux paramtres de la date systme Cryptage du mot de passe 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 Traces des mutations des paramtres et des donnes de base (paramtres de scurit, plan de comptes, donnes de base crditeurs et dbiteurs, etc.) Interdiction de supprimer
Mcanisme de protection daccs par des profils de groupe ou des autorisations individuelles. Enregistrement automatique des anciennes valeurs dans un fichier historique (avec date de validit: valable ds le / jusquau, date de la mutation et identification de lutilisateur qui a effectu la modification) Protection des accs aux paramtres et au fichier historique. 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 lectronique, 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 connaissance 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 attention 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 disposition 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 systmes 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 interne 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 de bilan CA Salaires Montant en millier 675123 59123 Processus Facturation Gestion du personnel Application utilise SAP FI SAP HR Commentaire / prsystmes Interfaces FACTURE et LIVRAISON ASP extern Type Standard Standard Exploitation Utilisation Int. Out. Centralise Centralise
Inventaire des principales interfaces Les interfaces dentre et de sortie dune application de type financier doivent tre considres comme des sources de risque. Il est important de les identifier et de les contrler. Nom de linterface Type Applications en amont/aval Type de flux Frquence Listes derreur Evaluation des risques
17
4 Identification des risques et des contrles cls

Vue densemble
Contenu et objectif Cette tape consiste dlimiter le primtre daudit qui sera ensuite valu et test. Elle consiste notamment 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 galement analys (par ex. exhaustivit, authenticit, valuation, rattachement lexercice ou reprsentation dans les comptes annuels).
ess Proc
us m
tie
App
ion licat
Syst
me
s IT
Infr
ITA
u astr
e IT ctur
= Risques = Contrle
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 implments 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 risques 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 contrles5: Risques Questce qui pourrait se passer? Contrles Qui contrle quoi, comment? Oprationnelle Activit Assertions dans les tats financiers6 Impact Efficacit des contrles Conception des contles Conservation Le contrle est-il capable de remplir les critres? Fonctionne- Efficacit ment des contles Oui / non Les contrles sont- / n.a. ils raliss?
Principe du justificatif
Dlimitation priode
Droits et obligations
Comptabilisation
Historisation
Autorisation
Authenticit
Auditabilit
Imputation
Evaluation
Contrle
Prventif
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.
5 6
Lefficacit des contrles est examine dans les tapes dcrites au chapitre 7. Il existe galement diffrents modles de rfrence concernant les assertions dans les tats financiers, par ex. celui du Manuel suisse daudit 1998.
20
Dtectif
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 description 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 conformment aux rgles de gestion dfinies. Le tableau ci-dessous prsente deux exemples: Description Rgle de gestion 3-Way Match Aucune facture nest paye si la commande, le bon de commande et la facture ne concordent pas (tolrance de 10%) Rfrence la fonction 3-Way-Match dERP Sparation des fonctions Sparation des fonctions entre comptables dbiteurs et crditeurs. Les personnes qui paient les factures ne peuvent pas crer de nouveaux fournisseurs Rles spars des comptables dbiteurs et crditeurs et pour la gestion des donnes de base. Documentation dune matrice de sparation des fonctions
Conception du contrle
21
5 Tests de cheminement
Vue densemble
Contenu et objectif Avant dentreprendre un test de cheminement, le processus global doit tre compris, du dbut la fin. 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, dpend 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 (financiers) pouvant rsulter du processus. Dans ce cas, il dduira ses procdures daudit orientes rsultat partir des risques identifis. 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.
Contexte
Procdure
Donnes de flux Une transaction est slectionne par classe de transaction. Son traitement est analys via le processus global, en commenant 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 traitements 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
Prsentation des informations 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 sousprocessus ou des applications individuelles, les interfaces qui les relient sont souvent oublies.
23
6 Evaluation de la conception des contrles

Vue densemble
Contenu et objectif Dans les prcdentes tapes, lauditeur a identifi les principaux risques et contrles cls et a acquis une 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 (couverture 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 niveau 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 fonctionnement (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 raisonnable 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.
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 automatiques? Les contrles en aval, cest--dire dtectifs, sont-ils remplacs, quand cela est possible, par des contrles en amont, autrement 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 financires? 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.
8
Menzies 2006, p 271 et s.
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 automatiques 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 potentiel optimise les diffrents contrles du processus, les complte ou mme les remplace. Souvent, en raison des courts dlais impartis pour la mise en place de systmes de contrle interne, les objectifs de contrles sont raliss de manire redondante 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 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 conformit 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 considre 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 objectif Lvaluation du fonctionnement des contrles (Test of Operating Effectiveness, TOE) permet lauditeur 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. 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 dcoulent de la stratgie daudit.
Contexte
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 11
Grant Thornton 2007, p. 5. 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 gnralement 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 surviennent 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 manuels. Le choix dun contrle par chantillonnage partir dune population de cas tester est judicieux lorsque cette population 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 Annuel Trimestriel (fin de priode incluse, c.--d. +1) Mensuel Hebdomadaire Quotidien Plusieurs fois par jour 1 1+1 2 5 15 25 Eleve 1 1+1 3 8 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 changements 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 surviennent 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 adapte). La NAS 400 dfinit galement les limites du contrle interne que lauditeur doit prendre en compte lors de son valuation. 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 objectif Dans ltape de conclusion, les rsultats des diffrentes tapes de laudit sont valus et synthtiss dans 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. 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.
Contexte
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 ncessitent 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
Prsentation des informations 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 galement 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 dveloppements 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 commerciale. 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 squentiellement 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 nouveaux 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). vrifi au cas par cas. Ces contrles sont souvent implments hors des applications (par ex. dans des systmes de base de donnes). Ceci doit toutefois tre
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 systmatique 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, voicemail, 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 galement 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 application. 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 bureautiques, 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 publis; 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 affect 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 exemple assorties dune date de validit). Les donnes transactionnelles sont sans cesse renouveles par les processus oprationnels 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 documents 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 composants 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 commandes 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 (procdures 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 attendant 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 fonctionnement 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 habituellement 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 contraignant conclure que les tats financiers ne concordent pas, tous les gards importants, avec les normes de prsentation 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 (gnralement 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 organisations de services de prsenter leurs activits et leur processus de contrles leurs clients et aux auditeurs dans un format 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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Guide Audit Applications

Загружено:

Авторское право:

Доступные форматы

Guide daudit des applications informatiques

Une approche inspire des audits financiers

Guide daudit des applications informatiques

Table des matires

Prsentation gnrale et introduction

et ilan ts du b ta lyse e rsul d Ana

s ri n de catio les cls ti Iden t contr e hem de c inem

Dlimitation de lapproche de contrle

couvert par la mthode

Contrles dapplications IT Intgralit Exactitude Validit Autorisation Sparation des fonctions

non couvert par la mthode

ase e/b war

1 Analyse du bilan et du compte de rsultats

Assertions dans les tats nanciers, par ex.: Authenticit

valuation Intgralit Droits et obligations

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

Cots Inventaire Equipements Crditeurs Frais de personnel Assurances Immobilisation Divers

422234 57000 121000 45000 121111 13000 121000

Gestion ressources humaines Etc Bouclement Consolidation

Contrats, services Valeur Positions dune filiale

Amortissement Positions consolides

ic teg Stra ales s

tive era Op sales

cha Pur ing s gic

g te Stra hasin purc

Job ation par Sh reh Wa ous e in opp g

Pro re Wa ods Go cept re d Ven or hou se

Billi ory g ent Inv ountin acc l r na g Inte untin o acc

ts oun le Acc eivab rec

ory g ent Inv ountin acc e n oic Inv catio ti ver a

ets g Ass untin o acc ts oun Accayable p

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

4 Identification des risques et des contrles cls

6 Evaluation de la conception des contrles

PS 400: Evaluation des risques et contrle interne RZ27.

Menzies 2006, p 271 et s.

7 Evaluation du fonctionnement des contrles

Grant Thornton 2007, p. 5. NAS 500 lments probants de contrle, RZ 19 ss.

Ernst&Young, Evaluating Internal Controls. p. 10.

Annexe 1 - Contrles lis aux applications

Exigences suprieurs et contrles lis aux applications

Types de contrles lis aux applications

Вам также может понравиться