Infrastructure IT
Systèmes IT
Applications
Processus métier
© ITACS Training
Auteurs: Peter R. Bitterli • Jürg Brun • Thomas Bucher • Brigitte Christ • Bernhard Hamberger • Michel Huissoud Daniel Küng • Andreas Toggwyler • Daniel Wyniger • Georges Berweiler (revue de la traduction française)
Guide d’audit des applications informatiques
Une approche inspirée des audits financiersNovembre 2008
1
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Guide d’audit des applications informatiques
Novembre 2008
2
Cet ouvrage est le fruit des réflexions et des expériences des membres de la Commission informatique de la Chambre fidu-
ciaire suisse. Travaillant dans les principaux cabinets d’audit comptables et financiers suisses ou dans d’importants services
d’audit interne, ceux-ci ont voulu saisir, structurer et standardiser l’approche qui est la leur dans le cadre de l’audit des
comptes annuels.Ce document a vocation à servir de passerelle entre les auditeurs financiers et les auditeurs informatiques
et devrait renforcer l’indispensable cohérence entre les travaux de ces deux disciplines. Ce texte reflète l’expérience et la
réflexion de ses auteurs. Il est publié avec l’aimable autorisation de la commission informatique de la Chambre fiduciaire
suisse. Copyright ISACA Switzerland Chapter, 2008.
Auteurs:
Peter R. Bitterli
Jürg Brun
Thomas Bucher
Brigitte Christ
Bernhard Hamberger
Michel Huissoud
Daniel Küng
Andreas Toggwyler
Daniel Wyniger
Georges Berweiler (revue de la traduction française)
Graphiques et mise en page: Felice Lutz, ITACS Training AG
3
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Table des matières
Table des matières 3
Présentation générale et introduction 4
Analyse du bilan et du compte de résultats 7
Identification des processus métier et des flux de traitement des données 9
Identification des applications de base et des principales interfaces IT pertinentes 13
Identification des risques et des contrôles clés 18
Tests de cheminement 22
Evaluation de la conception des contrôles 24
Evaluation du fonctionnement des contrôles 28
Appréciation globale 32
Annexe 1 - Contrôles liés aux applications 36
Annexe 2 - Glossaire 38
4
Présentation générale et introduction
But de l’approche Dans le cadre des procédures d’audit orientées processus et basées sur l’utilisation d’applications informatiques, il est essentiel de prendre en compte tous les do-maines importants, y compris les des domaines IT spécifiques ayant une influence significative sur l’objectif de contrôle de l’auditeur. Pour y parvenir une approche de contrôle intégrée (auditeur et auditeur informatique) est nécessaire. L’absence de procédure concertée entre auditeurs et auditeurs informatiques (auditeurs IT) constitue à cet égard un risque élevé. .
Le présent document décrit, dans le cadre des procédures d’audit orientées pro-cessus, une méthode de vérification et une approche intégrée de l’audit des con-trôles applicatifs destinées à prévenir ce risque d’audit.
Etendue et délimitation La méthode présentée se limite à la procédure de contrôle des applications IT au sein d’un processus métiers. Les domaines connexes sont abordés dans la mesure où ils ont un lien avec la procédure de contrôle, mais ils ne seront pas traités en détail. Il s’agit par exemple des contrôles par échantillonnage, des qualifications des auditeurs et des «contrôles IT généraux» (vérifications indépendantes d’une application).
L’utilisation de l’approche n’est pas limitée à l’audit des critères réglementaires; la procédure a été conçue sciemment de manière plus générique afin de convenir également à d’autres vérifications (par ex. vérifications de conformité).
Utilisateurs Les exemples et la description de la procédure se réfèrent à l’audit des états fi-nanciers. Compte tenu de son caractère générique, l’approche de contrôle est utilisable aussi bien par l’auditeur financier que par l’auditeur IT.
L’audit des états financiers d’une entreprise représente pour les auditeurs financiers un nombre de défis de plus en plus
grand; d’un côté l’évolution rapide des normes comptables, de l’autre l’automatisation croissante de la préparation des
états financiers au moyen de systèmes d’information toujours plus complexes. Ce deuxième aspect est le sujet qui est dé-
veloppé ci-après.
La qualité des informations financières dépend dans une large mesure de la qualité des processus métiers et des flux de
traitement des données s’y rapportant. Il est donc logique que l’auditeur concentre son travail sur ces processus métiers et
intègre le contrôle des applications correspondantes dans son approche d’audit.
L’approche présentée ci-après est destinée à aider l’auditeur financier à développer une approche d’audit intégrée et à
recentrer la procédure d’audit de manière plus efficace et plus ciblée sur les risques, en intégrant l’audit des processus
métiers pertinents et des applications correspondantes. L’approche commence donc avec l’analyse des états financiers de
l’entreprise et se termine par l’appréciation de l‘impact des résultats d’audit sur ces états financiers.
5
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Il est judicieux d’analyser les états financiers afin d’orienter
les procédures d’audit des processus de l’entreprise et des
applications correspondantes sur les tests des comptes fi-
nanciers significatifs et sur les risques d’audit s’y rapportant.
Cette analyse lie les principales positions comptables aux
processus métiers pertinents ou, plus concrètement, déter-
mine les flux de traitement des données à l’origine des prin-
cipales positions comptables et des applications de base qui
supportent ces flux de traitement des données.
Une fois les applications de base identifiées, l’auditeur
s’intéresse à la qualité du système de contrôle. Il détermine
d’abord si la conception du système de contrôle est adaptée
à la situation de risque actuelle des processus de l’entreprise
et enfin si les contrôles prévus sont implémentés et sont
efficaces.
L’évaluation du système de contrôle des processus métiers
pris en compte dans le cadre de l’audit permet à l’auditeur
de savoir s’il peut s’appuyer sur les procédures de production
des états financiers et, le cas échéant, de définir l’étendue
des procédures d’audit substantives supplémentaires qu’il
doit effectuer.
La présente méthode ne traite pas, de manière explicite, les «contrôles IT généraux». L’auditeur doit évaluer et tester systé-
matiquement les contrôles IT généraux afin de définir une stratégie de test adaptée aux contrôles applicatifs. Les contrôles
IT généraux sont dans une large mesure déterminants pour savoir si un contrôle applicatif, dont la conception est considérée
comme effective, a fonctionné pendant toute la période d’audit, ou si l’auditeur doit l’évaluer explicitement, par exemple
par le biais de tests directs (par ex. procédures de validations détaillées).
La méthode de contrôle repose sur un modèle à quatre niveaux. Ce modèle est présenté de manière schématique et simpli-
fiée ci-après. Dans la réalité, les interactions peuvent être beaucoup plus complexes, la schématisation permet simplement
de comprendre l’approche de contrôle.
Appréciation globaleEvaluation du fonctionnement du contrôleEvaluation de la conception du contrôle
Test de cheminement
Identification des risques
et contrôles clés
4
5
6
7
8
Identification des applications clés
et interfaces
Identification des processus opérationnels
et flux de données
Analyse du bilan et du compte
de résultats
1
2
3
Les 8 étapes de la méthode de vérification:
6
Délimitation de l’approche de contrôle
Contrôles d’applications IT• Intégralité• Exactitude• Validité • Autorisation • Séparation des fonctions
Contrôles IT généraux • Environnement de contrôle IT (polices, directives)• Développement de programmes• Modifications IT• Exploitation IT• Gestion des accès• Sécurité des systèmes• Sécurité des données
no
n c
ou
vert
p
ar la
mét
ho
de
cou
vert
p
ar la
mét
ho
de
Processus métier / transactions
Applications financières
Middleware / base de données
Systèmes d’exploitation / réseau
La figure ci-dessus montre, sous forme simplifiée, le modèle en couches utilisé dans la présente approche de contrôle.
Chacune des quatre couches représente un type de processus et de ressource.
• La couche supérieure (bleue) contient les principaux processus (manuels) de l’entreprise présentés typiquement par
domaines d’activités et subdivisés en sous-processus et en activités individuelles.
• La deuxième couche (rouge) contient les éléments automatisés des processus de l’entreprise, les applications IT à
proprement parler. A l’exception peut-être des PME de petite taille, la majorité des opérations commerciales dans toutes
les entreprises est traitée à l’aide d’applications IT.
• La troisième couche (jaune) contient les systèmes IT de base. Ce terme recouvre une grande diversité de plates-formes
possibles supportant les applications de la deuxième couche. Exemple: systèmes de gestion de base de données (par ex.
Oracle, DB2), composants de base d’applications intégrées (par ex. SAP Basis, Avaloq, …) ou des systèmes plus techniques
(par ex. Middleware).
• La couche inférieure (verte) contient les éléments d’infrastructure informatique. Pour l’essentiel, cette couche contient les
éléments matériels (Mainframe, systèmes périphériques, serveurs) ainsi que les composants du réseau et les systèmes de
surveillance technique y relatifs.
L’approche présentée dans ce document traite principalement des deux couches supérieures (signalées par une flèche verte)
autrement dit, des contrôles liés aux applications au sein des processus métiers et des applications sous-jacents. Les deux
dernières couches, l’infrastructure IT et les processus IT sous-jacents (signalés par une flèche rouge) sont bien entendu
importants du point de vue de l’auditeur mais ne sont pas traités dans le cadre présent.
7
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Vue d’ensemble
Procédure
Infrastructure IT
© ITACS Training
© ITACS Training
Systèmes IT
Applications
Processus métier
RISQUE
RISQUE
RISQUE
RISQUE
Assertions dans les états financiers, par ex.:
Authenticité
Évaluation
Intégralité
Droits et obligations
Principaux comptespar ex. débiteurs
Contenu et objectif
Nous considérons que l’objectif de contrôle est la conformité de la tenue de la comptabilité. La procédure est la suivante:• définition des positions du bilan et du compte de résultats pertinentes pour l’audit• identification des transactions (opérations commerciales) ou des classes de transaction1 à l’origine de
ces positions.
Contexte L’analyse2 du bilan et du compte de résultats est centrale dans le cadre d’un audit ciblé et orienté sur les risques, et sert à identifier les positions du bilan et du compte de résultats pertinentes, c’est-à-dire im-portantes pour l’audit. L’analyse fournit à l’auditeur des informations clés pour l’identification des risques et l’identification des développements ayant une influence sur les comptes annuels. Elle sert en même temps d’instrument de planification pour la définition des points de contrôle principaux et des méthodes de vérification2 utilisées.
1 Analyse du bilan et du compte de résultats
1 Une classe de transaction est un ensemble de transactions ou d’opérations commerciales au sein d’un processus d’entreprise qui reposent sur une même base et qui peuvent être comptabilisées de manière quasiment identique.
2 Manuel suisse d’audit, 1998, chapitre 3.2424 Analyse des comptes annuels
8
Identification des comptes et groupes de comptes significatifs
L’auditeur procède à une évaluation des risques pouvant avoir une influence sur les états financiers en orientant ses procé-
dures d’audit sur ces risques. A cet égard, la définition du caractère significatif joue un rôle central.
Il s’agit d’identifier les comptes ou les groupes de comptes qui dépassent le seuil de matérialité3 et par conséquent entrent
dans le champ d’audit.
Sont également identifiés les comptes ou les groupes de comptes dont l’existence ou les évolutions comportent des risques
spécifiques ou signalent des risques spécifiques, par exemple une évolution inattendue de certains indicateurs.
Identification des transactions et des classes de transactions significatives
Une fois les groupes de compte identifiés, l’auditeur peut, dans une deuxième 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 d’une analyse
de données, les écritures qui ont été effectuées sur certains comptes spécifiques. Il est alors possible de déduire de ces
données quelles opérations commerciales ou transactions ont été à l’origine de ces écritures. Cela peut s’effectuer dans un
environnement ERP en répartissant les écritures électroniques dans les comptes significatifs par «code transaction».
L’auditeur remonte ainsi des principaux comptes et groupes de comptes au travers des principales transactions aux opéra-
tions à partir desquelles ces transactions ont été générées.
L’avantage de cette approche rétrospective est qu’elle exclut d’emblée les classes de transactions non significatives résultant
des subdivisions de processus. Lorsque l’auditeur connaît les classes de transactions significatives et les opérations commer-
ciales qui les génèrent, il peut procéder à l’analyse des risques aux différentes étapes du processus comme décrit à l’étape
suivante.
Particularités
Dans le cadre du contrôle des applications IT, l’auditeur se concentre généralement sur les transactions de routine sachant
que la plupart d’entre elles sont gérées par l’application et que c’est là qu’ont lieu la plupart des contrôles automatisés et
ceux liés aux systèmes informatiques. Les transactions non routinières, en particulier les procédures d’estimation, font fré-
quemment l’objet d’un système de contrôle principalement manuel.
L’auditeur devrait, à ce stade de sa mission, prendre également en compte les principaux événements de l’entreprise qui ont
eu une influence sur les comptes ou classes de transactions sélectionnés. Ex.:
• introduction d’une nouvelle application informatique
•migration ou regroupement d’applications ou de données
3 Manuel suisse d’audit, 1998, chapitre 3.114: «Ont un caractère significatif, tous les éléments qui influencent l’évaluation et la présentation des comptes individuels, des comptes du groupe ou certains de leurs postes, modifiant ainsi l’assertion au point d’influencer les décisions des destinataires des comptes individuels ou des comptes du groupe concernant l’entreprise.»
9
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Vue d’ensemble
Procédure
Identification des processus significatifs
Sur la base des transactions identifiées, l’auditeur identifie les processus qui influent sur ces positions. L’analyse s’étend
par exemple du processus ponctuel de clôture des comptes annuels (avec influence directe sur le montant d’une 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 résultat auront le même processus comme «source».
Les processus peuvent judicieusement être représentés sous forme de cartographie de processus dans un tableau ou un gra-
phique. Les deux formes de représentation présentent des avantages qu’il peut être utile de combiner en cas d’interactions
de processus complexes.
Utilisation de la documentation existante
Si disponible, l’auditeur doit s’appuyer sur la documentation des processus existante auprès de l’entreprise. La documen-
tation se concentre généralement sur les activités et précise, pour chaque étape de processus, les entrées, les traitements
et résultats ainsi que les rôles des différents acteurs. Toutefois, ce type de documentation contient rarement les risques de
processus ou les contrôles clés, ceux-ci doivent donc être identifiés et documentés par l’auditeur dans une phase ultérieure
des travaux liés aux contrôles des applications.
Création d’une nouvelle documentation – formes de représentation
L’auditeur doit acquérir une connaissance approfondie des processus sélectionnés. Il convient, à cet égard, de distinguer
les processus métier (par ex. processus de vente) et les processus financiers parfois très ponctuels (par ex. consolidation des
chiffres trimestriels d’une succursale ou calcul de l’amortissement annuel d’une immobilisation). Ces deux catégories de
processus comportent des risques susceptibles de se matérialiser dans les états financiers.
Contenu et objectif
Identification des processus métiers significatifs qui sont à l’origine des transactions et classes de transac-tions précédemment identifiées. Par «processus métiers significatifs» on entend les principaux processus qui ont une influence directe sur le flux de traitement comptable. Il s’agit du processus de comptabilité en tant que tel, de processus métiers complexes tels que la facturation et les processus de support, par ex. dans le domaine des ressources humaines. Les processus IT tels que définis dans COBIT par exemple ne sont pas concernés4.
Contexte Les états financiers d’une entreprise sont le résultat de la consolidation de plusieurs activités que l’on peut regrouper en processus et qui peuvent être très différents les uns des autres (processus complexes, limi-tés dans le temps; processus pouvant influencer plusieurs transactions, etc.). Potentiellement, certaines faiblesses de ces processus peuvent remettre en cause la fiabilité des états financiers. C’est pourquoi une identification minutieuse des processus métiers et des flux de traitement des données est indispensable pour pouvoir évaluer les risques au sein de chaque processus.
2 Identification des processus métier et des flux de traitement des données
4 Un processus peut être défini comme «une chaîne de tâches manuelles, semi-manuelles ou automatisées servant à l’élaboration ou au traitement d’informations, de produits ou de services. Exemples: vente, relance, production, inventaire, comptabilité, etc.».
10
Présentation sous forme de tableau. – solution adaptée à des éléments comptables et interactions simples.
Présentation sous forme de graphique (forme de flux de traitement) - solution adaptée
à des interactions complexes
Exemple A
Position de bilan ou du compte de résultats
Montant en milliers de CHF
Résultat (Output) Processus Entrée (Input)
Chiffre d’affaires 675’123 Factures Vente Contrats, services fournis
Coûts InventaireEquipementsCréditeurs
422’23457’000
121’00045’000
Paiements Achat Commandes
Frais de personnel Assurances
121’11113’000
Paiements Gestion ressources humaines
Contrats, services
Etc…
Immobilisation 121’000 Amortissement Bouclement Valeur
Divers Positions consoli-dées
Consolidation Positions d’une filiale
Production
Materials
manage-
ment
Purcha-
sing
Sales
ControllingAccounting
Strategic
purchasing
Operating
purchasing
Vendor
Goods
recept
Invoice
vertification
Accounts
payable
MRP
Inventory
accounting
Warehouse
Assets
accounting
Work
schedulingEngineering
Job
preparation
Production
Internal
accounting
GL
accounting
Overhead cost
management
Inventory
accounting
Billing
Warehouse
Shopping
Customer
MRP
Accounts
receivable
Operative
sales
Strategic
sales
Raw
materials
Finished
production
Materials
manage-
ment
11
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Exemple B
Présentation graphique (forme de flux de traitement des données). En cas d’analyse d’interactions complexes.
Mar
ché
Mar
ché
Corporate Governance
Processus de pilotage
Category Management (CM)
Acquisition (achat/dispatching)
Logistique
Vente
Processus de définition des objectifs Contrôle de gestion
Stratégie Organisation d’entreprise Gestion du personnel
Finances/Services
Processus de support
Informatique Personnel/formation
Communication Gestion de la qualité Gestion immobilière
Gestion des emplacements Services internes Production
12
Particularités
Degré de détail
Une description trop générale rend difficile l’identification des risques. Inversement, un degré de détail trop élevé peut nuire
à l’analyse et à la lisibilité. Selon la complexité d’un processus, il peut être utile de le subdiviser en plusieurs sous-processus.
Gestion des paramètres et des données de base
Pour certains processus métiers, il est conseillé de considérer la gestion (première saisie, mutations et suppression) des pa-
ramètres et des données de base comme deux sous-processus distincts.
• Les paramètres d’une application IT sont les valeurs constantes utilisées pour un même type de transaction (par ex. taux
de retenue pour la caisse de pension dans une application de calcul de salaire).
• Les données de base sont les attributs permanents d’un objet, par ex. données de base créditeurs, données de base clients,
données de base produits
Interfaces manuelles
L’objectif de cette étape est de comprendre le flux de traitement des informations et des données pertinentes. Il ne s’agit
pas de considérer uniquement les données électroniques; une analyse complète prend également en compte des flux de
documents (par ex. rapport sur l’évaluation des stocks) et des interfaces manuelles.
Exemples
• Le processus d’achat est composé des sous-processus gestion des données de base fournisseurs, facturation fournis-seurs et comptabilisation des achats.
• Le processus de vente est composé des sous-processus gestion des données de base clients, facturation clients et comp-tabilisation des ventes.
• Le processus de salaire est composé des sous-processus gestion des données de personnel, préparation du décompte du salaire, fixation du salaire, décompte du salaire et comptabilisation du salaire.
13
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Vue d’ensemble
Contenu et objectif
Identification des applications IT concernées et de leurs interfaces
Contexte De nombreux contrôles sont automatisés et intégrés dans les applications IT. De plus, l’automatisation des étapes de processus présente des risques inhérents supplémentaires. Il peut s’agir par exemple de la difficulté de mettre en œuvre une séparation adéquate des fonctions, mais également d’une impossibi-lité de contrôle humain compte tenu du niveau élevé d’intégration, du traitement en temps réel et du principe de «single point of entry», lesquels génèrent un traitement et un enregistrement automatiques des transactions.
Il est donc utile d’identifier à temps les applications impliquées, leurs caractéristiques et leurs interfaces. Ces informations permettent de définir de manière détaillée l’étendue de l’audit et d’élaborer un pro-gramme d’audit.
3 Identification des applications de base et des principales interfaces IT pertinentes
Infrastructure IT
Systèmes IT
Applications
Processus métier
© ITACS Training
14
Procédure
Elaboration d’une cartographie des applications
Une représentation des applications impliquées n’est pas toujours superposable avec le flux des données. En particulier avec
les applications fortement intégrées (par ex. Enterprise Resource Planning Systems, ERP), plusieurs processus métiers sont pris
en charge par une seule et même application (par ex. couplage automatique d’un processus d’achat avec un processus de
vente).
Exemple
Inventaire et catégorisation des applications pertinentes du point de vue financier
Nous distinguons les différents types d’applications ci-après. Compte tenu de leurs profils de risque très différents, les types
de programmes sont une caractéristique importante pour la planification et la réalisation de l’audit et doivent donc être
documentés:
• application standard
• application standard fortement adaptée
• développement interne
SALAIRE
EXCELFACTURE
COMPTA
15
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Applications standard
Les applications standard au bénéfice d’une certaine maturité présentent généralement une multitude de contrôles
intégrés pertinents. Le tableau ci-après montre, à titre d’exemple, quelques contrôles de base destinés à assurer l’intégrité
des transactions traitées:
En outre, les contrôles énumérés ci-dessous sont également très importants:
• valider les données (par ex. listes de sélection, formules de validation, etc.),
• piloter le traitement (job control, ordre de traitement journalier, mensuel, de fin d’année, etc.),
• déroulement des transactions (par ex. gestion du workflow, contrôles des limites, principes des 4 yeux et signature élec-
tronique, vérification de la concordance entre commande/livraison/facture),
• gérer les dépenses (disponibilité des rapports, etc.).
Lors de l’évaluation des applications standard il convient de répondre par ex. aux questions suivantes:
• quel type d’application standard l’entreprise utilise-t-elle?
• l’application standard est-elle répandue dans son secteur d’activité?
• l’application standard est-elle certifiée?
• s’agit-il d’un progiciel établi, connu ou d’une nouveauté?
• existe-t-il des sources d’informations sur cette application et, éventuellement, des faiblesses de sécurité ou de processus
connues (remarque: les applications standards contiennent parfois des erreurs et l’auditeur doit disposer d’une connais-
sance suffisante sur les sources d’erreur connues).
• l’auditeur dispose-t-il de connaissances et d’expériences personnelles relatives à l’application?
Une application de comptabilité standard devrait disposer des fonctionnalités suivantes (liste non exhaustive)
Ces fonctionnalités offrent (ou impliquent) les contrôles suivants
Datation automatique des opération et des transactions par le système
Protection de l’accès aux paramètres de la date système
Offrir plusieurs identifications utilisateurs avec des mécanismes d’authentification
Cryptage du mot de passe
Contrôle de la syntaxe du mot de passe
Contrôle de la validité du mot de passe
Historique des tentatives de connexion échouées
Paramétrisation des autorisations Mécanisme de protection d’accès par des profils de groupe ou des autorisa-tions individuelles.
Traces des mutations des paramètres et des données de base (paramètres de sécurité, plan de comptes, données de base créditeurs et débiteurs, etc.)
Enregistrement automatique des anciennes valeurs dans un fichier historique (avec date de validité: valable dès le / jusqu’au, date de la mutation et identi-fication de l’utilisateur qui a effectué la modification)
Protection des accès aux paramètres et au fichier historique.
Interdiction de supprimer Le programme ne doit pas proposer de fonction de suppression des données.
16
Les réponses servent, conformément à la norme NAS 310 chiffre 10, à «l’identification des domaines requérant une at-
tention ou une connaissance particulières». Elles fournissent à l’auditeur un aperçu des risques inhérents à l’application
utilisée.
Si l’auditeur conclut que l’application standard ne présente pas de faiblesses connues dans les domaines qui le concernent,
il peut limiter ses efforts dans les étapes suivantes de l’approche d’audit des applications au niveau de l’identification des
risques et l’évaluation des contrôles pertinents. Au minimum, il doit s’assurer que:
• les contrôles sur lesquels il compte s’appuyer existent et fonctionnent
• en cas de paramètres d’application, que ceux-ci étaient actifs pendant la période d’audit concernée.
Applications standard fortement adaptées
Par applications standard fortement adaptées, nous entendons des progiciels dont le but principal est de mettre à dis-
position des fonctionnalités de base et des outils de création de processus et de workflows, et dont la paramétrisation
permet la mise en place de solutions spécifiques qui répondent aux besoins de l’entreprise. L’auditeur est ici confronté à
un grand défi dans la mesure où, même s’il dispose d’informations sur la fiabilité des composants des applications et sy-
stèmes éprouvés, il n’en a pas sur l’interaction de ces composants avec les éventuelles configurations et programmations
supplémentaires dans l’environnement spécifique du client. En pareilles situations, l’auditeur devra prévoir davantage de
temps pour l’identification des risques et l’évaluation des contrôles pertinents. Plus une application standard a été adaptée
aux exigences spécifiques d’une entreprise, plus l’analyse des paramètres, de la gestion du workflow et des adaptations
techniques des programmes est importante.
Développements internes
Dans le cas de développements internes, l’auditeur n’est pas en mesure de s’appuyer sur les informations et les expériences
généralement connues et doit adapter sa procédure d’audit à l’application concernée. Les applications développées en in-
terne exigent généralement un travail de vérification plus important. En pareilles situations, la collaboration entre l’auditeur,
le responsable de l’application et, le cas échéant, le développeur de l’application revêt une grande importance.
Dans le cas d’applications standards fortement adaptées et d’applications développées en interne, l’auditeur s’appuiera,
pour des raisons d’efficacité, et dans la mesure du possible, sur des tests documentés au sein de l’entreprise. Si les tests
correspondant n’existent pas ou ne sont pas pertinents (concept ou documentation de test lacunaires, erreurs non corrigées
après les tests, absence de prise en main formelle par les utilisateurs, etc.), il doit réaliser lui-même les tests nécessaires à
sa vérification.
Exploitation de l’application par des tiers ou au sein de l’entreprise
L’externalisation de domaines d’activités ou de processus métiers comporte des risques inhérents et des risques d’audit
supplémentaires compte tenu de la délégation de responsabilité. La question de l’organisation d’un audit chez le prestataire
de services est particulièrement pertinente: le standard de vérification NAS 402 (ou SAS 70) doit être pris en compte dans
ce cas.
17
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Utilisation centralisée ou décentralisée de l’application
De même, en raison des responsabilités déléguées mais également d’une complexité technique souvent considérable (par
ex. en termes d’intégrité liée à des procédures de sauvegardes redondantes des données ou des séquences de traitement
au travers de plusieurs périodes ou zones temporelles différentes), l’utilisation décentralisée d’une application comporte des
risques inhérents et des risques d’audit supplémentaires qui augmentent la complexité de l’audit.
Représentation des informations
Représentation sous forme de tableau
Inventaire des principales interfaces
Les interfaces d’entrée et de sortie d’une application de type financier doivent être considérées comme des sources de ris-
que. Il est important de les identifier et de les contrôler.
Position de bilan
Montant en millier
Processus Application utilisée
Commentaire / pré-systèmes
Type Exploitation Utilisation
CA 675’123 Facturation SAP FI Interfaces FACTURE et LIVRAISON
Standard Int. Centralisée
Salaires 59’123 Gestion du personnel
SAP HR ASP extern Standard Out. Centralisée
Nom de l’interface
Type Applications en amont/aval
Type de flux Fréquence Listes d’erreur Evaluation des risques
18
Vue d’ensemble
Contenu et objectif
Cette étape consiste à délimiter le périmètre d’audit qui sera ensuite évalué et testé. Elle consiste notam-ment à définir pour chaque risque significatif des scénarios d’erreurs, afin d’évaluer la manière dont ils peuvent être compensés par des contrôles clés. Il s’agit donc à la fois de réduire l’impact et la probabilité de survenance de ces erreurs. Par ailleurs, l’impact sur les assertions dans les états financiers est égale-ment analysé (par ex. exhaustivité, authenticité, évaluation, rattachement à l’exercice ou représentation dans les comptes annuels).
Contexte Compte tenu de la complexité des processus et des applications, il est important de se concentrer sur l’essentiel lors des travaux d’audit. L’identification des risques et des contrôles clés attendus constitue la base pour un audit efficace.
Les contrôles clés attendus par l’auditeur sont ensuite comparés aux contrôles effectivement implémen-tés et la couverture des risques est évaluée.
4 Identification des risques et des contrôles clés
= Risques
= ContrôleInfrastructure IT
Systèmes IT
Applications
Processus métier
© ITACS Training
19
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Procédure
Risques, objectifs de contrôle et contrôles
Au sein des principaux processus et des systèmes impliqués, les risques qui peuvent entraîner une inexactitude importante
dans les états financiers sont identifiés. Le résultat obtenu est un aperçu des risques susceptibles d’empêcher la réalisation
des objectifs du processus. Cette analyse des risques permet également de définir l’étendue des procédures d’audit.
Les objectifs de contrôle découlent des risques. Un objectif de contrôle est défini comme une assertion relative au résultat
souhaité (but) devant être atteint grâce à l’implémentation du contrôle. Les objectifs de contrôle sont donc souvent des
risques «inversés», autrement dit, ils visent la diminution d’un risque donné.
Par la suite, l’auditeur définit les attentes relatives aux contrôles typiques et attendus pour les risques identifiés. Il convient
de subdiviser ces contrôles en «contrôles clés» et autres contrôles. Les contrôles clés, individuels ou combinés entre eux,
sont indispensables à une réduction acceptable des risques. Ils sont donc garants de la fiabilité des résultats du processus
et des données financières. Les contrôles clés constituent «la colonne vertébrale» du système de contrôle et sont donc des
objets de vérification essentiels. Les autres contrôles ont une pertinence moindre pour l’auditeur.
Les contrôles clés attendus par l’auditeur sont comparés aux contrôles effectivement mis en place et la couverture des ris-
ques est évaluée dans le cadre des contrôles clés existants dans le processus concerné.
Frameworks standard
Il existe des inventaires génériques de risques typiques, des objectifs de contrôle et des pratiques de contrôle pour divers
processus et applications. Le Framework COBIT® en est un exemple connu dans le domaine des processus informatiques.
Un autre exemple de contrôles d’application génériques est illustré dans l’annexe 1. Ces moyens auxiliaires peuvent être très
utiles lors de l’audit mais ne remplacent pas le jugement professionnel de l’auditeur lors de l’évaluation du processus.
Types de contrôle
Les questions suivantes sont pertinentes pour le déroulement de l’audit et doivent donc être documentées:
• contrôles préventifs versus contrôles détectifs: le but d’un contrôle clé est-il d’empêcher la survenance d’une erreur ou de
la détecter?
• contrôles automatiques versus contrôles manuels: un contrôle est-il réalisé manuellement ou est-il automatisé dans une
application?
20
Présentation des informations
La matrice des risques et des contrôles présente dans la partie gauche les risques identifiés et leur couverture par les con-
trôles5:
Un élément supplémentaire au centre de cette matrice des risques et des contrôles permet d’indiquer l’assertion6 des états
financiers concernés par le contrôle clé. Cela garantit la couverture de toutes les exigences par les contrôles identifiés.
La partie droite de la matrice peut servir dans les étapes suivantes de l’approche d’audit à documenter l’évaluation de la
conception des contrôles et l’évaluation de leur fonctionnement.
Particularités
Exhaustivité des risques et des contrôles
L’identification des contrôles au sein des transactions n’est pas suffisante en soi; il convient également de considérer les
risques et les contrôles inhérents aux paramètres et aux données de base. Les contrôles typiques sont les contrôles d’accès
et les autorisations.
Tous les contrôles importants liés aux applications doivent être pris en compte, autrement dit, tous les contrôles manuels
ou automatiques qui ont une influence directe sur le résultat du processus. La qualité des contrôles ayant une influence
indirecte (par ex. les contrôles IT généraux) doit être évaluée dans le cadre de l’appréciation globale de l’audit mais ne fait
pas l’objet d’explications plus détaillées dans ce document.
Risques Contrôles Acti-vité
Assertions dans les états financiers6 Im-pact
Efficacité des contrôles
Qu’est-ce qui pourrait se pas-ser?
Qui con-trôle quoi, comment?
Opé
ratio
nnel
le
Con
trôl
e
Aut
hent
icité
Eval
uatio
n
Dél
imita
tion
pério
de
Dro
its e
t ob
ligat
ions
Impu
tatio
n
Com
ptab
ilisa
tion
Aut
oris
atio
n
Prin
cipe
du
just
ifica
tif
His
toris
atio
n
Con
serv
atio
n
Aud
itabi
lité
Prév
entif
Dét
ectif
Concep-tion des contôles
Fonctionne-ment des contôles
Efficacité
Oui / non / n.a.
Le contrôle est-il capable de remplir les critères?
Les con-trôles sont-ils réalisés?
5 L’efficacité des contrôles est examinée dans les étapes décrites au chapitre 7.6 Il existe également différents modèles de référence concernant les assertions dans les états financiers, par ex. celui du Manuel suisse d’audit 1998.
21
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Concentration sur les contrôles clés
Si l’auditeur ne se concentre pas sur les contrôles clés, l’audit risque d’être trop général et inefficace. De même, une descrip-
tion trop détaillée des contrôles attendus est déconseillée, car elle entraînerait des coûts subséquents trop élevés et serait
sans réel intérêt supplémentaire.
Documentation des contrôles d’application
Pour la compréhension des contrôles applicatifs et en particulier pour l’évaluation ultérieure de la conception des contrôles,
une documentation appropriée des contrôles revêt une importance fondamentale. La documentation doit permettre à
l’auditeur de comprendre quelles sont les «règles de gestion» devant être garanties par le contrôle. De plus, elle doit faire
apparaître les décisions liées à la conception du contrôle prises dans la perspective de l’implémentation du contrôle. Enfin,
elle doit faire état des paramètres ou des réglages personnalisés pertinents pour que le contrôle puisse se dérouler confor-
mément aux «règles de gestion» définies.
Le tableau ci-dessous présente deux exemples:
Description 3-Way Match Séparation des fonctions
Règle de gestion Aucune facture n’est payée si la comman-de, le bon de commande et la facture ne concordent pas (tolérance de 10%)
Séparation des fonctions entre comptables débiteurs et créditeurs. Les personnes qui paient les factures ne peuvent pas créer de nouveaux fournisseurs
Conception du contrôle Référence à la fonction 3-Way-Match d’ERP Rôles séparés des comptables débiteurs et créditeurs et pour la gestion des données de base.Documentation d’une matrice de séparation des fonctions
22
Vue d’ensemble
Procédure
Données de flux
Une transaction est sélectionnée par classe de transaction. Son traitement est analysé via le processus global, en commen-
çant par l’initiation 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 générateur, puis au travers des différentes étapes
de traitement dans l’application. Lors du déroulement du processus, les contrôles existants sont vérifiés et la sélection de
contrôles clés analysée.
Dans le cadre du test de cheminement, le personnel doit être interrogé sur sa compréhension des descriptions de fonction
et des consignes de contrôle, en particulier en ce qui concerne le traitement des exceptions dans le processus ou les traite-
ments des erreurs.
Questions devant être prises en compte durant le test de cheminement du processus:
• à qui faire appel pour obtenir des explications sur les détails, par ex. du domaine d’activité?
• de qui / d’où proviennent les documents, rapports, diagrammes de flux, copies d’écran etc. existants?
• quelle activité de contrôle a lieu au cours des différentes activités?
• l’audit est-il effectué pour éviter une erreur ou pour l’identifier?
• comment et à quelle fréquence le contrôle est-il effectué (automatique ou manuel)?
• le contrôle automatique est-il réellement opérationnel?
• quelles traces le contrôle laisse-t-il?
Contenu et objectif
Avant d’entreprendre un test de cheminement, le processus global doit être compris, du début à 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 d’une transaction type servant d’exemple. Il sert à vérifier la compréhension du processus concerné, les risques et les contrôles y relatifs mais également à confirmer l’analyse précédente.La profondeur, respectivement le degré de détail avec lequel un test de cheminement est effectué, dé-pend de l’intention de l’auditeur de s’appuyer ou non sur le système de contrôle existant.• Si l’auditeur a l’intention de s’appuyer sur les contrôles, il analysera en détail le fonctionnement des
différents contrôles pendant le test de cheminement afin de savoir s’ils couvrent effectivement les risques existants ou non.
• Si l’auditeur n’a pas l’intention de s’appuyer sur l’efficacité des contrôles, il se contentera d’un test de cheminement moins détaillé. Il doit garantir que l’auditeur comprend tous les risques principaux (finan-ciers) pouvant résulter du processus. Dans ce cas, il déduira ses procédures d’audit orientées résultat à partir des risques identifiés.
Contexte Le test de cheminement permet de vérifier systématiquement:• la compréhension des flux de traitement,• la consistance et la pertinence de la documentation et du diagramme de flux existants,• la correction et l’exhaustivité des informations sur les contrôles pertinents et• l’existence des contrôles pertinents dans les activités quotidiennes.
5 Tests de cheminement
23
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Présentation des informations
La documentation du test de cheminement, durant lequel les étapes manuelles ou automatiques du processus ou de la
classe de transaction sont vérifiées, est normalement élaborée sur la base de descriptions, diagrammes de flux, de copies
d’écran, de documents, etc.
Particularités
Dans la pratique, le test de cheminement s’accompagne souvent de l’évaluation de la conception du contrôle et, dans le
cas de contrôles automatiques, également de l’évaluation du fonctionnement des contrôles. Dans la présente approche
d’audit, ces deux étapes constituent la suite logique du test de cheminement et sont traitées séparément dans les deux
chapitres suivants.
Les tests de cheminement sont souvent divisés en plusieurs parties. C’est pourquoi, au cours du déroulement des sous-
processus ou des applications individuelles, les interfaces qui les relient sont souvent oubliées.
24
Vue d’ensemble
Procédure
Evaluation de la conception des contrôles
Le système de contrôle interne est présumé effectif lorsque les contrôles sont respectés et donnent une assurance raison-
nable que les erreurs ou les abus n’affectent pas de manière significative les états financiers. Certaines procédures d’audit
orientées processus sont conçues pour attester que la conception des contrôles permet d’identifier, d’éviter et de corriger
des erreurs importantes. Les éléments probants d’efficacité des contrôles durant toute la période sous revue ne peuvent être
apportés qu’à l’étape suivante «Evaluation du fonctionnement des contrôles»7.
Contenu et objectif
Dans les précédentes étapes, l’auditeur a identifié les principaux risques et contrôles clés et a acquis une compréhension approfondie du processus qui a été vérifiée dans le cadre du test de cheminement.L’adéquation des différents contrôles, pris individuellement, a fait l’objet d’un premier examen. L’évaluation de la conception des contrôles qui suit (design effectiveness) examine l’adéquation (couver-ture des risques, exhaustivité, actualité) et l’efficacité économique (redondances, chevauchements) de l’ensemble du système de contrôle interne en tenant compte des principaux processus métier dans leur globalité. La conception des contrôles, notamment leur positionnement dans le processus métier, doit être évaluée pour savoir si:• les risques identifiés sont entièrement couverts,• les objectifs de contrôle définis peuvent être réellement atteints par les contrôles mis en place,• les contrôles permettent réellement de réduire les risques d’erreur et de fraude et si la couverture des
risques s’effectue de manière efficace et économique,• ou si, le cas échéant, un autre contrôle ou combinaison de contrôles, notamment de contrôles au ni-
veau de l’environnement de l’entreprise, est plus efficace pour réaliser le même objectif de contrôle.
Le but de cette étape consiste à atteindre une qualité de contrôle adéquate avec le moins possible de contrôles.
Seule une compréhension approfondie de la conception des contrôles permet de définir une stratégie d’audit appropriée pour l’évaluation du fonctionnement des contrôles.
Contexte Une analyse minutieuse de la conception des contrôles (Design Effectiveness) permet: • d’identifier les lacunes, les chevauchements et les doublons en matière de contrôles;• d’éviter la réalisation onéreuse de contrôles par les services et, le cas échéant, les tests de fonctionne-
ment (Operating Effectiveness) des contrôles par l’auditeur en cas de contrôles inappropriés;• d’envisager que le même résultat ou un meilleur résultat peut être obtenu avec l’utilisation ou
l’adaptation d’autres contrôles, notamment de contrôles déjà établis.
7 PS 400: Evaluation des risques et contrôle interne RZ27.
6 Evaluation de la conception des contrôles
25
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Procédures d’audit
Les procédures d’audit d’évaluation de la conception des contrôles comportent des questions, des observations, des tests de
cheminement, la revue de la documentation principale et l’évaluation de l’adéquation de contrôles spécifiques. L’auditeur
forme son opinion sur la conception des contrôles en:
• interrogeant les membres de la direction de l’entreprise et les collaborateurs ayant des tâches de surveillance ainsi que les
collaborateurs impliqués dans la réalisation du contrôle;
• consultant les documents relatifs aux transactions et les autres documents importants de l’entreprise;
• observant les activités spécifiques d’exécution et de contrôle;
• suivant les transactions individuelles dans le système d’information (test de cheminement).
Conformément aux normes d’audit en vigueur, les procédures d’audit d’évaluation de la conception des contrôles «Design
Effectiveness» doivent être documentées par des éléments probants (évidences d’audit).
Questions relatives à l’évaluation de la conception des contrôles
L’interrogation des collaborateurs du domaine contrôlé à l’aide de quelques questions types, permet parfois sous forme
d’un processus itératif d’identifier des faiblesses importantes dans la structure du contrôle8.
• Les étapes du processus et les contrôles qui s’y rapportent sont-ils organisés dans un ordre logique et judicieux?
• La responsabilité de la réalisation des contrôles est-elle définie sans ambiguïté?
• Les contrôles peuvent-ils être réalisés de manière correcte et judicieuse?
• Les contrôles hybrides ou entièrement manuels sont-ils remplacés, dans la mesure du possible, par des contrôles automa-
tiques?
• Les contrôles en aval, c’est-à-dire détectifs, sont-ils remplacés, quand cela est possible, par des contrôles en amont, au-
trement dit préventifs?
• Les contrôles sont-ils conformes aux exigences des directives et des procédures de travail?
• Les informations nécessaires à la réalisation du contrôle sont-elles disponibles?
• Le déroulement du processus ou du contrôle permet-il l’établissement d’un document de contrôle compréhensible?
• Les contrôles sont-ils réalisés par un agent qualifié et compétent dans ce domaine?
• Les contrôles sont-ils réalisés dans un délai adéquat et avec une fréquence appropriée?
• La conception des contrôles peut-elle être mise en œuvre dans le cadre des restrictions organisationnelles et finan-
cières?
Une approche dite portefeuille de contrôles permet d’évaluer les contrôles en termes de niveau d’automatisation (manuels,
semi-automatiques, automatiques), d’impact (préventifs, détectifs), de fréquence de contrôle et de couverture de risque.
Concernant le niveau d’automatisation, les contrôles automatiques sont plus efficaces que les contrôles manuels car ils ont
un fonctionnement continu dans le temps et un coût d’implémentation unique. De plus, leur efficacité est plus stable tant
qu’aucune modification significative n’est effectuée dans l’application.
Il est communément admis que les contrôles préventifs permettent plus facilement d’atteindre les objectifs de contrôle que
les contrôles détectifs qui visent l’identification d’erreurs en aval des traitements.
En règle générale, une fréquence élevée de contrôles manuels et semi-automatiques entraîne des coûts et des délais
plus élevés par rapport à des contrôles automatiques dont la fréquence n’a pratiquement pas d’influence sur les coûts
d’exploitation. En revanche, une fréquence d’exécution peu élevée d’un contrôle manuel ou semi-automatique peut nuire à
son efficacité. Un contrôle qui couvre plusieurs objectifs de contrôle ou différents risques est en principe considéré comme
plus efficace, plus fiable et plus économique qu’un contrôle ciblé sur un seul risque.
8 Menzies 2006, p 271 et s.
26
Questions techniques relatives à l’évaluation de la conception des contrôles
Dans le cadre de l’évaluation de la conception des contrôles applicatifs, l’auditeur clarifie les conditions techniques requises
pour que le contrôle se déroule comme prévu. L’auditeur se posera notamment les questions suivantes:
• le contrôle peut-il être contourné ou forcé (contournement, procédure d’exception, super user)?
• dans quelle mesure le contrôle dépend-il de la paramétrisation?
• dans quelle mesure le contrôle dépend-il du système d’autorisation?
• qui contrôle le système d’autorisation?
• dans quelle mesure le contrôle dépend-il des données de base?
• qui contrôle les données de base?
• le fonctionnement du contrôle peut-il être enregistré pour une vérification ultérieure (traces d’audit)?
Particularités
Potentiel d’optimisation
Pour préserver les aspects économiques du système de contrôle, il faut se demander si les contrôles définis sont nécessaires
et s’ils ne chevauchent pas d’autres contrôles de processus ou contrôles au «niveau de l‘entreprise»(Entity level controls9) ou
ne sont pas redondants. Les contrôles en amont, c’est-à-dire les contrôles préventifs, mais également les contrôles automa-
tiques représentent un potentiel d’économie considérable ainsi qu’une assurance élevée au niveau de leur appréciation.
Il convient, pour identifier le potentiel d’amélioration de la conception des contrôles, d’utiliser le savoir et les expériences
provenant du domaine d’activité de l’entreprise concernée, ainsi que les appréciations de la direction et des collaborateurs.
Outre les faiblesses déjà connues, l’analyse des contrôles au «niveau de l’entreprise» offre un potentiel considérable
d’amélioration de la conception des contrôles. Compte tenu de son influence globale sur l’ensemble des processus, ce po-
tentiel optimise les différents contrôles du processus, les complète ou même les remplace. Souvent, en raison des courts dé-
lais impartis pour la mise en place de systèmes de contrôle interne, les objectifs de contrôles sont réalisés de manière redon-
dante dans le cadre de contrôles de processus et de contrôles «au niveau de l’entreprise». Il y a toutefois lieu de vérifier si
les contrôles «au niveau de l’entreprise»assurent une réaction immédiate ou s’ils ne sont en mesure d’apporter une réponse
adéquate qu’à moyen terme. D’autres redondances et chevauchements peuvent être identifiés lors de l’harmonisation de
la conception des contrôles dans les processus métiers et de support.
9 Les contrôles «au niveau de l’entreprise» tels que par exemple les contrôles IT généraux ont une portée globale dans l’entreprise ou dans le groupe et sont habituellement gérés dans les dimensions du cube COSO suivantes: l’environnement de contrôle, l’évaluation des risques, le système d’information et la communication ainsi que la surveillance. Il s’agit de directives et de procédures internes à toute l’entreprise ayant une portée considérable sur la confor-mité de l‘activité commerciale en termes de stratégie, d’objectifs ou d’aspects culturels. A l’inverse des contrôles de processus, les contrôles «au niveau de l’entreprise» (en général) ont une portée abstraite mais plus large. [Menzies 2006, p. 21].
27
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Contrôles clés inopérants
Dans le cadre de son appréciation de la conception des contrôles, lorsque l’auditeur identifie des contrôles clés qu’il con-
sidère comme inopérants, le système de contrôle à évaluer présente alors une lacune. Pour la combler, il doit identifier
d’autres contrôles clés ou des contrôles compensatoires et évaluer leur efficacité. Dans ce cas, l’auditeur doit toujours garder
à l’esprit la sélection complète de contrôles clés pour éviter de créer des redondances coûteuses.
Effort de test
Une adaptation de la sélection des contrôles clés s’impose également lorsqu’il apparaît, lors du test de cheminement ou de
l’évaluation de la conception des contrôles, que l’effort pour tester un contrôle clé est disproportionné.
28
Vue d’ensemble
Procédure
Etapes de l’évaluation
L’évaluation du fonctionnement des contrôles comprend les étapes suivantes:
• sélection des contrôles à vérifier, dans la mesure où il n’est pas nécessaire de contrôler l’ensemble des contrôles
• choix de la stratégie de test (procédures d’audit orientées processus contre procédures d’audit orientées résultat)
• choix de la procédure de test, et notamment de la taille de l’échantillon
• réalisation des opérations d’audit orientées processus ou orientées résultat
• evaluation des exceptions relevées et de l’importance des erreurs et des faiblesses constatées
Procédure de contrôles orientée résultat pour l’obtention d’éléments probants (évidences d’audit)
L’auditeur obtient des éléments probants pour l’évaluation des contrôles par le biais de procédures d’audit orientées résultat.
Ces activités se subdivisent en contrôles ponctuels (revue d’enregistrements ou de documents, observation, questions ou
confirmations, recalcul, mise en application ou répétition du contrôle) et procédures d’audit analytiques (par ex. au moyen
d’une analyse des données)11. Généralement, l’observation et le questionnement ne garantissent qu’une assurance d’audit
moyenne. Les contrôles ponctuels sont utilisés en particulier pour les contrôles faiblement documentés ou pas documentés.
En revanche, la vérification ou la répétition d’un contrôle ponctuel garantissent un niveau d’assurance d’audit élevé. Les
contrôles manuels sont généralement testés au moyen d’une combinaison de questions, d’observations, de consultations
des documents de contrôle et, si nécessaire, par la répétition du contrôle.
Stratégies de test dans le cadre des contrôles d’application
• Test unique (Test-of-One): un contrôle programmé doit en principe être testé une seule fois. Après quoi on considère,
à condition que l’environnement IT soit stable et que les contrôles IT généraux ont fonctionné durant toute la période
d’audit, qu’il fonctionne de manière efficace. Lors du test, l’auditeur doit vérifier que le contrôle testé fonctionne comme
prévu dans l’ensemble des situations pertinentes possibles.
• Test direct: le fonctionnement du contrôle est vérifié sur la base d’un échantillonnage ou par analyse des données de
transactions.
Contenu et objectif
L’évaluation du fonctionnement des contrôles («Test of Operating Effectiveness», TOE) permet à l’auditeur d’émettre une opinion sur le système de contrôle interne. Elle vise à définir l’efficacité d’un contrôle («Operating Effectiveness») en évaluant que le contrôle fonctionne comme prévu et qu’il a été exécuté entièrement par une personne qualifiée et autorisée10.
Contexte Seul le test de fonctionnement des contrôles fournit au management responsable et à l’auditeur l’assurance nécessaire pour apprécier le fonctionnement réel des contrôles pendant toute la période d’audit, la couverture des risques et des objectifs de contrôles. La nécessité et l’étendue des tests décou-lent de la stratégie d’audit.
7 Evaluation du fonctionnement des contrôles
10 Grant Thornton 2007, p. 5.11 NAS 500 Éléments probants de contrôle, RZ 19 ss.
29
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
• Baselining / Benchmarking: l’objectif de cette stratégie est de réduire l’étendue des travaux de contrôles durant les périodes
d’audit suivantes. Pour ce faire, les résultats des tests d’un contrôle d’application sont repris dans les périodes de contrôle
suivantes. Les tests réalisés durant la première période d’audit servent d’ancrage. S’il est attesté qu’aucune modification n’a
été apportée au contrôle d’application dans la période suivante et que les contrôles IT généraux pertinents ont été testés
avec succès, l’efficacité des contrôles d’application est considérée comme effective et ne fait pas l’objet de nouveaux tests.
A intervalles réguliers, le contrôle doit toutefois faire l’objet d’un nouvel ancrage. Cette stratégie de test est applicable
lorsque par ex. un contrôle d’application dépend clairement d’une configuration ou si les éventuelles modifications sont
clairement visibles. La stratégie ne devrait pas être appliquée lorsque le nombre de modifications apportées au système
est élevé, et ce, en raison des effets secondaires possibles et en cas de contrôles IT généraux instables.
•Analyse des données: l’efficacité d’un contrôle est vérifiée au moyen d’une analyse des données assistée par ordinateur.
Dans le cas idéal l’analyse porte sur l’ensemble des données pertinentes.
Test de contrôles contre test de transactions end-to-end
Aujourd’hui, la plupart des auditeurs identifient les contrôles dans le cadre du flux de transactions puis testent et évaluent
leur efficacité sous forme de contrôles ponctuels. Cette procédure ne correspond toutefois pas à l’approche choisie géné-
ralement lors de l’implémentation des applications. L’objectif visé est de contrôler les fonctionnalités de l’application au
moyen de jeux de tests complets. Les jeux de tests sont conçus pour toutes les opérations commerciales significatives et
sont réalisés de bout en bout à l’aide de l’application. En pareilles situations, il devrait être possible de réaliser des synergies
considérables lorsque l’auditeur est associé à la définition des jeux de tests et a la possibilité de contribuer à la conception
des tests couvrant non seulement la fonctionnalité opérationnelle mais également la fonctionnalité souhaitée des contrôles
clés. Cette procédure peut également constituer un ancrage pour une approche de tests ultérieure dite «Baselining».
Tests de non-régression
Par test de non-régression, on désigne la répétition de l’ensemble ou d’une partie des jeux de tests afin de détecter
d’éventuels effets secondaires liés aux modifications des parties déjà testées d’une application. Ces modifications sur-
viennent régulièrement, par exemple à la suite de mises à jour, de changements et de corrections logicielles. Le test de
non-régression est une procédure de test appropriée aux applications faisant fréquemment l’objet de changements ou
d’adaptations. Le test de non-régression est particulièrement efficace lorsqu’il peut être automatisé.
En relation avec l’approche de test implicite (décrite plus haut) du contrôle par des tests de bout-en-bout des transactions
commerciales, le test de non-régression permet d’attester le fonctionnement de contrôles d’application faisant l’objet de
modifications régulières avec un coût supplémentaire faible.
30
Procédure de test, choix / taille de l’échantillonnage
Les contrôles par échantillonnage sont utilisés pour contrôler le fonctionnement d’un nombre important de contrôles ma-
nuels. Le choix d’un contrôle par échantillonnage à partir d’une population de cas à tester est judicieux lorsque cette popu-
lation de cas à contrôler satisfait au moins aux exigences particulières du PCAOB (par ex. Auditing standard n° 5, AS5) ou
du IT Governance Institute. Exemple d’une application du standard AS5:
Questions relatives à l’évaluation du fonctionnement des contrôles
Les facteurs suivants peuvent influencer la procédure de contrôle ainsi que le niveau d’assurance obtenu par l’auditeur12:
• fréquence de réalisation du contrôle: plus la fréquence de réalisation d’un contrôle manuel est faible, plus la quantité de
cas à contrôler est faible.
• importance du contrôle: plus l’auditeur s’appuie sur un contrôle ponctuel pour former son opinion d’audit, plus ce contrôle
doit être testé.
• validité du justificatif de contrôle: si le contrôle génère des évidences liées à l’efficacité de son fonctionnement (traçabilité,
exhaustivité, exactitude, horodatage), la quantité de cas à tester peut être plus faible qu’en cas de contrôle sans justificatifs
documentés.
• importance relative des constats d’erreurs ou de différences. Celles-ci sont variables selon l’importance, la complexité et
la quantité des transactions traitées.
•management Override: évaluation de la probabilité de contourner ou de forcer un contrôle par une personne responsable.
• fréquence de changement des contrôles: l’efficacité du contrôle peut être considérablement influencée par des change-
ments touchant le contrôle lui-même ou le processus environnant
Evaluation des exceptions lors du test des contrôles
Lorsque l’auditeur rencontre une exception par rapport au résultat de test attendu, il doit établir s’il s’agit d’un cas isolé,
statistiquement prévisible, et donc acceptable. Si en revanche, aucune différence n’était prévisible ou si les différences sur-
viennent fréquemment, il convient d‘analyser leur origine. Pour vérifier si le nombre d’exceptions ne dépasse pas une limite
acceptable, il est possible, par exemple, d’élargir les travaux de test du contrôle par échantillonnage. Si le résultat du test
par échantillonnage fait apparaître des contrôles inopérants, des contrôles compensatoires sont identifiés. Si cette recherche
aboutit à des contrôles compensatoires inopérants, la procédure d’audit doit être adaptée.
Fréquence ou périodicité des contrôles Taille minimale des échantillons, risque d’erreur
Faible Elevée
Annuel 1 1
Trimestriel (fin de période incluse, c.-à-d. +1) 1+1 1+1
Mensuel 2 3
Hebdomadaire 5 8
Quotidien 15 25
Plusieurs fois par jour 25 40
12 Ernst&Young, Evaluating Internal Controls. p. 10.
31
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Influence de la taille de l’entreprise
Selon la norme d’audit NAS 400, l’auditeur doit obtenir le même degré d’assurance indépendamment de la taille de
l’entreprise; toutefois, il peut tenir compte du fait que certains contrôles internes ne sont pas praticables pour de petites
entreprises ou de petites unités d’organisation. Ainsi, une séparation des fonctions insuffisante (Segregation of Duties)
peut être remplacée par un contrôle direct fort du management (contrôle compensatoire), ou l’auditeur peut compenser
l’absence d’évidences de contrôle ou d’éléments probants par des contrôles orientés résultat (stratégie de contrôle adap-
tée). La NAS 400 définit également les limites du contrôle interne que l’auditeur doit prendre en compte lors de son éva-
luation. L’auditeur qualifie le risque d’audit comme élevé lorsque les contrôles ne peuvent éviter, identifier et corriger une
anomalie importante.
Particularités
Documentation des résultats du contrôle
La description doit porter en particulier sur:
• l’objet du contrôle, l’auditeur, la date
• les contrôles vérifiés (version incluse), objectifs de contrôle vérifiés
• la procédure de test utilisée (contrôle par échantillonnage, ensemble des cas)
• le résultat des tests, indication du type, timing (périodicité) et de l’étendue des tests
• les détails suffisants pour qu’un tiers compétent en la matière (par ex. un autre auditeur) soit en mesure de comprendre
l’efficacité des tests en termes d’évaluation du risque d’audit.
• de plus, l’auditeur doit également définir les origines des exceptions, le statut de la mise en œuvre des mesures
d’amélioration ou des informations qualitatives complémentaires.
• en cas d’exceptions ou de différences importantes, l’auditeur doit fournir les informations suivantes: taille du contrôle par
échantillonnage (si opportun), nombre d’exceptions ou de tests échoués, type et cause de l’exception.
32
Vue d’ensemble
Procédure
Résultats
Les résultats individuels des procédures d’audit réalisées jusqu’ici sont compilés. Pour les contrôles manquants ou mal
conçus ainsi que les contrôles qui n’ont pas fonctionnés de manière effective pendant la période d’audit, l’impact sur les
rapports financiers doit être évalué. Les assertions dans les comptes annuels constituent le lien entre l’application et les
rapports financiers. Elles formulent les objectifs posés aux positions des comptes annuels et doivent être contrôlées afin de
savoir si des lacunes dans les contrôles pourraient, avec une certaine probabilité, avoir un impact négatif sur la réalisation
des objectifs.
Malgré les moyens auxiliaires existants et utilisés (frameworks, listes de contrôle, etc.), les conclusions des travaux néces-
sitent le recours au jugement professionnel de l’auditeur pour tenir compte des particularités de l’entreprise, des exigences
liées aux processus et celles spécifiques aux risques. Cela exige une discussion approfondie au sein de l’équipe de révision
afin de définir les procédures d’audit supplémentaires.
Contenu et objectif
Dans l’étape de conclusion, les résultats des différentes étapes de l’audit sont évalués et synthétisés dans une appréciation globale en fonction de leur influence sur les rapports financiers.L’auditeur émet une opinion sur l’adéquation du système de contrôle interne et sa capacité à éviter des erreurs majeures dans les états financiers, avec un niveau d’assurance raisonnable.De plus, une appréciation globale est rendue sur: • dans quelle mesure l’application contrôlée supporte le processus métier (conception des contrôles,
fonctionnement des contrôles)• la présence de lacunes de contrôle significatives dans l’application• l’impact des lacunes de contrôle sur les traitements de l’application et sur le processus global ainsi que
sur les assertions s’y rapportant dans les états financiers• la présence, dans le processus métier, de contrôles qui compensent l’impact d’éventuelles faiblesses
de contrôle dans l’application et sur les vérifications de contrôle et les procédures d’audit orientées résultat supplémentaires nécessaires.
Contexte Lorsque les faiblesses des contrôles applicatifs peuvent influencer significativement l’exactitude de l’opinion sur les états financiers, et que ce risque ne peut pas être compensé par d’autres contrôles (p. ex. des contrôles manuels détectifs), l’impact de ces faiblesses sur le rapport annuel doit être évalué. Cette évaluation se fait à partir des trois points de vue suivants:1. s’agit-il d’un fait qui affecte l’état financier?2. s’agit-il d’une violation de la loi ou des statuts?3. s’agit-il d’un élément qui affecte l’opinion d’audit? Lors de l’évaluation de l’impact sur l’opinion d’audit,
l’auditeur évalue la possibilité de couvrir l’impact possible des contrôles inopérants par des procédures d’audit substantives.
Les indicateurs de contrôles applicatifs inopérants peuvent être notamment: le contournement (override) ou la désactivation (disable) de contrôles, l’utilisation erronée d’informations générées par ordinateur, des données de base et de pilotage erronées, des contrôles IT généraux inopérants, des éléments probants de contrôles manquants, une prédominance arbitraire de contrôles uniquement détectifs ou préventifs. Les réflexions auxquelles l’auditeur doit se prêter lors de l’évaluation des contrôles sont définies dans la norme NAS 700.
8 Appréciation globale
33
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Présentation des informations
L’auditeur établit à l’intention de la direction, outre son opinion d’audit, une synthèse de la situation des risques au niveau
des processus et des applications contrôlés.
Particularités
Les exceptions identifiées lors de l’évaluation des contrôles clés et non corrigées par des contrôles compensatoires doivent
être évaluées, par définition, de manière plus critique que les déficiences des autres contrôles.
34
Une entreprise doit implémenter les mesures nécessaires pour garantir la sécurité et la conformité des applications et donc
des processus métiers. Chaque processus d’affaire, sous-processus ou activité doit donc être piloté d’une manière ou d’une
autre pour atteindre les objectifs définis. On parle ici du terme «contrôles», qui désigne «tous les concepts, procédures,
pratiques et structures d’organisation permettant de vérifier avec une assurance raisonnable la réalisation des objectifs
d’entreprise et la prévention ou l’identification et la correction d’événements non désirables».
Le terme contrôle vient de l’anglais «control» et signifie entre autres commande, dispositif pour manœuvrer, mais égale-
ment maîtrise, supervision, pilotage ou guidage, ce qui dépasse de loin le sens habituel et plutôt limité que l’on donne au
terme contrôle.
Chaque application et donc chaque processus commercial spécifique contient des contrôles qui garantissent la réalisation
des objectifs définis. Ces contrôles sont appelés «contrôles applicatifs». Il s’agit par exemple de contrôles d’exhaustivité,
d’exactitude, de validité et de séparation de fonction. Outre les contrôles liés aux applications, il existe des contrôles non
liés aux applications, appelés également contrôles IT généraux. Il s’agit par exemple de contrôles dans le domaine des dé-
veloppements de système, des modifications, de la sécurité et de l’exploitation. Ces contrôles ne sont pas traités dans ce
chapitre.
Il est évident que chaque type d’application exige des contrôles différents: chaque activité commerciale spécifique comporte
des risques commerciaux différents, inhérents à cette activité et susceptibles d’empêcher l’atteinte des objectifs.
Exigences supérieurs et contrôles liés aux applications
Les contrôles applicatifs ont pour but d’assurer un traitement conforme et sûr des transactions et de fournir la preuve de
l’exactitude des résultats. Par conséquent, les contrôles jouent un rôle central dans la réalisation des objectifs d’entreprise,
de la protection du patrimoine, de l’exactitude et de la fiabilité de la comptabilité et du respect de la politique commer-
ciale.
Avec les contrôles applicatifs, l’entreprise garantit la saisie exhaustive, exacte, valide et vérifiable de toutes les transactions
commerciales significatives des processus métier ainsi que le traitement, l’enregistrement et l’édition de ces derniers par le
système. L’objet des contrôles liés aux applications est donc avant tout la saisie, l’enregistrement, le traitement et l’édition
de transactions et de données. Les contrôles liés aux applications s’étendent sur l’ensemble du processus commercial.
Types de contrôles liés aux applications
On distingue les types de contrôles applicatifs suivants:
1 Création et autorisation
2 Saisie et enregistrement des données
3 Traitement des données
4 Sortie des données (Output)
5 Interfaces
Annexe 1 - Contrôles liés aux applications
35
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
1 Création et autorisation
Les principaux objectifs relatifs à la création et à l’autorisation sont les suivants:
•minimiser les erreurs et les omissions
• identifier, documenter, communiquer et corriger les erreurs et les irrégularités dès leur apparition
• vérifier l’exactitude de la correction des erreurs par un service / une personne indépendante
• les opérations commerciales (transactions) ne sont effectuées que par des personnes habilitées et / ou selon des procédures
autorisées
• les personnes responsables de la saisie des transactions commerciales sont identifiées dans le système
• les justificatifs de saisie délivrés sont exhaustifs et exacts et sont transmis en temps utile
• les justificatifs de saisie sont conservés pendant la période légale et sous la forme prescrite ou peuvent être reconstitués
par l’organisation.
Les contrôles typiques concernant la création et l’autorisation sont les suivants:
• profils des compétences pour l’établissement de pièces comptables (par ex. règlement sur les signatures) et mise en œuvre
au travers un contrôle des autorisations par des systèmes de gestion des accès
• séparation des fonctions de création et de validation de pièces comptables
• visa ou signature sur les justificatifs de saisie
• formulaires de saisie compréhensibles et utiles (par ex. avec des champs préimprimés)
• processus d’identification précoce et de traitement des erreurs et des irrégularités
• collecte systématique des pièces comptables (par ex. dans l’ordre chronologique à l’aide d’un horodateur ou séquentielle-
ment à l’aide d’un système de numérotation continue)
•micro filmage ou numérisation des justificatifs et conservation sur un support permettant de reconstruire les informations
originales dans les délais requis.
2 Saisie et enregistrement des données
Les principaux objectifs de la saisie et de l’enregistrement des données sont les suivants:
• seules des personnes habilitées (ou les processus autorisés) peuvent enregistrer des données
• l’exactitude, l’exhaustivité et la validité des champs importants (par ex. numéros de compte, montants, code article) sont
contrôlées dans les écrans ou programmes en amont du processus de saisie
• les erreurs et les anomalies de saisie / d’enregistrement sont identifiées, documentées, communiquées et corrigées en
temps utile
• l’exactitude de la correction des erreurs est vérifiée par un service / une personne indépendante
Les contrôles typiques de saisie et d’enregistrement des données sont les suivants:
• profils des compétences pour la saisie / enregistrement des transactions et mise en œuvre au travers d’un contrôle des
autorisations par des systèmes de gestion des accès
•masques de saisie compréhensibles et conviviaux avec des contrôles de format de données intégrés (par ex. champs de
date, données numériques, champs obligatoires, etc. et liste de valeurs prédéfinies et récurrentes)
• contrôle automatique approfondi des valeurs saisies (par ex. dépassements de valeurs limites, contrôle de plausibilité des
contenus, synchronisation avec les données enregistrées)
• affichage des libellés de code complets après saisie du code (par ex. la désignation d’un article s’affiche à la saisie du
numéro d’article)
36
• comparaison des données saisies, c’est-à-dire comparaison des données à saisir avec les données visibles à l’écran ou avec
des journaux de saisie (compte tenu du coût, judicieux uniquement pour les transactions critiques telles que les mutations
de données de base notamment)
• totaux de contrôle par lots: nombre de documents (ex nombre de factures), somme de zones de valeurs figurant sur les
documents ou sommes numériques (montants, quantités), somme de contrôle (condensat, hash, addition mathématique
de numéros de documents, numéros de compte)
• contrôle de l’ordre d’apparition des pièces comptables numérotés en continue au sein d’un lot pour identifier les numéros
manquants ou les doublons de saisies
• comparaison des données saisies avec les valeurs enregistrées (par ex. postes ouverts avec des opérations comptables
nouvellement créées)
• saisie de contrôle (appelée également double saisie, contrôle des 4 yeux); saisie à double de valeurs importantes par
différentes personnes (géré par le système de gestion des accès) ou le cas échéant, par une seule et même personne (par
ex. lors de la saisie masquée d’un nouveau mot de passe)
• contrôle visuel des valeurs saisies généralement par une deuxième personne; convient pour les cas critiques et un petit
nombre de transactions
• processus d’identification précoce et de traitement d’erreurs et d’anomalies, les transactions corrigées devant être à nou-
veaux entièrement vérifiées
3 Traitement des données
Les principaux objectifs du traitement des données sont les suivants:
• l’exhaustivité, l’exactitude et la validité des traitements réalisés sont vérifiées selon une procédure de routine; les erreurs
de traitement sont identifiées au plus tôt, documentées et corrigées en temps utile
• la correction de transactions erronées se déroule sans entraver inutilement le traitement des autres transactions
• les calculs, totalisations, consolidations, analyses et affectations sont effectués correctement par le programme
• la séparation des fonctions est assurée y compris pendant le traitement des données
• les transactions générées automatiquement par l’application (par ex. intérêts sur crédit périodiques, commandes en cas
de dépassement du seuil de sécurité des stocks) font l’objet des mêmes contrôles d’exhaustivité, d’exactitude et de validité
que les transactions isolées
• les décisions importantes reposant sur des calculs automatiques sont prises et vérifiées par des personnes
Les contrôles typiques du traitement des données sont les suivants:
• un grand nombre des contrôles décrits précédemment pour la saisie et la création de données peuvent être appliqués pour
le traitement (par ex. comparaison des champs individuels, totaux de contrôle par lots, contrôle de l’ordre d’apparition et
comparaison de données, synchronisation automatique du grand livre et des livres auxiliaires). Il est cependant important
que les documents et les totaux utilisés pour les contrôles correspondent aux résultats de fin de traitement
• rapprochement des données traitées dans le système avec des confirmations externes (par ex. inventaires, confirmations
de soldes bancaires et de soldes de comptes)
• garantie de l’intégrité du traitement grâce aux quatre objectifs de processus supérieurs: atomicité (unité de travail non
divisible, toutes les actions s’y rapportant sont effectuées avec succès ou aucune d’entre elles ne l’est), consistance (lorsque
la transaction n’atteint aucun statut final stable, elle doit être réinitialisée dans le système ), isolation (le comportement
d’une transaction n’est pas influencé par d’autres transactions effectuées simultanément) et durabilité (à l’issue d’une
transaction, ses conséquences restent durables, y compris les changements en cas de pannes de système). Ces contrôles
sont souvent implémentés hors des applications (par ex. dans des systèmes de base de données). Ceci doit toutefois être
vérifié au cas par cas.
37
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
4 Sortie de données (output)
Les principaux objectifs de la sortie des données sont les suivants:
• la sortie des données s’effectue en temps utile, au bon endroit et conformément aux procédures définies
• l’exhaustivité et l’exactitude des informations éditées sont garanties par des procédures effectuées de manière systéma-
tique sur des totaux de contrôle et un rapprochement avec les totaux de contrôle correspondant du traitement
• le traitement, la conservation et la destruction d’output sont conformes aux exigences de la protection des données et
de sécurité (avant et après leur diffusion auprès des utilisateurs)
• les informations imprimées sont conservées conformément aux dispositions légales.
Les contrôles typiques de la sortie des données sont les suivants:
• les contrôles d’envoi et de réception règlent les modalités de communication des listes et autres outputs (qui, quand, quoi,
comment et en combien d’exemplaires)
• les systèmes de gestion des accès garantissent la traçabilité des accès des utilisateurs lors de consultations à l’écran ou de
commandes de listes en ligne
• les contrôles de numérotation et d’exhaustivité garantissent que la gestion, l’édition, la restitution, la réception et la
destruction (par ex. en cas de copie de contrôle) d’outputs critiques (par ex. chèques, bons, obligations de caisse, etc.)
s’effectuent conformément aux procédures
• l’exactitude et l’exhaustivité des impressions périodiques (par ex. traitement semestriel et annuel) sont contrôlées au
moyen des contrôles par échantillonnage.
5 Les interfaces
Les principaux objectifs relatifs aux interfaces sont les suivants:
• l’authenticité et l’intégrité des informations provenant de sources externes à l’organisation sont contrôlées soigneusement
avant d’entreprendre toute action potentiellement critique, indépendamment du moyen de réception (téléphone, voice-
mail, papier, fax, e-mail, ou fichier)
• les informations sensibles sont protégées pendant leur transmission par des mesures appropriées contre les accès non
autorisés, les modifications ou les adressages erronées
Les contrôles typiques au niveau des interfaces sont les suivants:
• un grand nombre des contrôles présentés précédemment pour la saisie et l’enregistrement des données peuvent égale-
ment être utilisés pour le contrôle des interfaces (par ex. comparaison des positions individuelles, totaux de contrôle de
lots, contrôle de numérotation et comparaison de données).
• authentification de chaque message à l’aide de procédures cryptographiques
• cryptage de chaque message (important) pour garantir
- la confidentialité du contenu
- l’intégrité du contenu du message
- l’identité de l’expéditeur.
Remarque: un grand nombre des contrôles réalisés au niveau des interfaces concernent principalement le transport et la
transmission ainsi que l’enregistrement électronique des données; il s’agit en général de contrôles non liés à une applica-
tion. Ces derniers ne seront pas détaillés dans ce document.
38
Annexe 2 – Glossaire
Applications
On distingue:
Les applications standard: les applications standard sont souvent des logiciels, utilisés ou vendus, qui ont été développés
pour un nombre important d’entreprises et généralement vendus plusieurs fois. Les applications standard typiques sont par
exemple des logiciels métiers spécifiques à des secteurs d’activité, des logiciels multifonctions tels que les logiciels bureau-
tiques, la gestion de workflow, la gestion de documents ou des logiciels spécialisés tels que les systèmes de gestion intégrée
ERP, CAD, les logiciels de distribution, les systèmes de gestion de marchandises et des inventaires, de comptabilité ou de
gestion des ressources humaines. L’avantage d’une application standard du point de vue du contrôle interne (SCI) est qu’un
grand nombre de développeurs et de clients travaillent sur l’application et donc contribuent à son amélioration permanente
(conception, développement, test et documentation).
Une application dédiée est généralement développée sur mesure pour une entreprise donnée ou pour répondre à un besoin
spécifique (en interne ou à des entreprises tierces). En comparaison avec les applications standards, le logiciel dédié présente
souvent plusieurs problèmes (ex. développeurs moins qualifiés, logiciels et matériels ne répondant pas aux exigences du
moment, solutions inabouties, implication inadéquate du mandant dans le développement, etc.).
Application Service Provider (ASP)
Le service d’«Application Service Provider»consiste à mettre à la disposition d’un client une application exploitée par un
fournisseur de services d’application (par ex. un système ERP) au travers d’un réseau public ou privé. Le logiciel n’est pas
acheté, mais seulement loué en cas de besoin. L’ASP se charge de toute l’administration, de la sécurité des données, de la
maintenance applicative etc. A la différence de l’hébergement d’application pur, l’ASP fournit également des services (par
ex. gestion des utilisateurs) autour de l’application.
Assertions (dans les états financiers)
Assertions explicites ou implicites de la direction retenues pour la préparation des états financiers. Elles peuvent être classées
de la manière suivante:
Existence: un actif ou une dette existe véritablement à la date de la clôture;
Droits et obligations: un actif ou une dette peut être attribué à l’entreprise à la date de clôture;
Evénement: une transaction ou un (autre) événement est survenu durant la période et est attribuable à l’entreprise;
Exhaustivité: il n’existe pas d’actif, de dette, de transaction ou d’autres événements non recensés ou de postes non pu-
bliés;
Appréciation: une dette figure au bilan avec une valeur appropriée;
Saisie et délimitation de période: une transaction ou un événement (quelconque) est saisi avec le montant correct et affec-
té à la période correcte et présentation et publication: un poste est publié, classé et formulé conformément aux normes
comptables applicables.
Baselining/Benchmarking pour les contrôles applicatifs
Stratégie de contrôle dans laquelle les résultats des tests des contrôles applicatifs sont repris dans les périodes de contrôle
suivantes: les contrôles applicatifs sont testés durant la première période de contrôle, la période dite baseline. A condition
de prouver qu’aucune modification n’a été apportée au contrôle applicatif dans la période suivante et que les contrôles IT
généraux pertinents ont été testés et sont efficaces, l’évaluation des contrôles applicatifs est considérée comme effective et
ne fait pas l’objet de nouveaux tests. L’objectif de cette stratégie de contrôle est de réduire l’étendue des contrôles orientés
résultat durant les périodes de contrôle suivantes.
39
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Benchmarking: voir Baselining
Business Rule
Terme technique désignant les règles de gestion devant être prises en compte dans les spécifications de l’application, son
développement, les tests et la livraison compte tenu de l’impact important qu’elles peuvent avoir, en tant qu’exigences de
contrôles clé, sur la conception du SCI.
Caractère significatif
Des informations ont un caractère significatif lorsque leur omission ou leur présentation erronée pourrait influencer des
décisions économiques des destinataires prises sur la base des états financiers. Le caractère significatif dépend de la taille
du poste ou de l’erreur résultant de circonstances particulières de l’omission ou de la présentation erronée. Le caractère
significatif est plutôt un seuil ou une valeur limite et moins une exigence qualitative première que doit avoir une information
pour pouvoir être utile.
Contrôles
Les contrôles sont des concepts, des procédures, des pratiques et des structures d’organisation permettant de vérifier
avec une assurance raisonnable la réalisation des objectifs d’entreprise et la prévention ou l’identification et la correction
d’événements non désirables.
On distingue entre autres:
Contrôles applicatifs
Les contrôles applicatifs sont des contrôles intégrés aux applications. Les objectifs des contrôles applicatifs portent sur des
applications spécifiques. Les contrôles typiques portent sur l’exhaustivité et l’exactitude des saisies et des traitements, sur
la validité des saisies, etc.
Contrôles IT généraux
Les contrôles IT généraux constituent la base pour un fonctionnement en bonne et due forme des contrôles applicatifs
automatisés. Les contrôles IT généraux couvrent les risques inhérents aux droits d’accès, à la qualité et à la sécurité des
données ou à la maintenance et aux changements des systèmes (matériel et logiciel).
Contrôles hybrides
Combinaison de contrôles manuels et automatiques
Contrôles compensatoires
Contrôles internes qui réduisent le risque d’une faiblesse existante ou potentielle susceptible d’occasionner une erreur ou
une omission.
Direction de l’entreprise
Personnes responsables de la surveillance, de la haute direction et du contrôle (Gouvernance) d’une entreprise (par ex. le
conseil d’administration d’une SA). Cette notion est utilisée dans les cas où l’on ne peut pas faire la distinction entre, d’une
part, les responsables de la gestion et du contrôle et, d’autre part, la direction des affaires.
40
Direction et surveillance
Personnes qui sont responsables de la surveillance, de la haute direction et du contrôle («Gouvernance») d’une entreprise
(par ex. le conseil d’administration d’une SA). Les membres de la direction ne font partie de ce cercle que lorsqu’ils assument
les fonctions précitées.
Données
On distingue:
Données de base: données «statiques» servant à l’identification, la classification et la description, souvent utilisées par
plusieurs applications et qui présentent un caractère relativement permanent. Les données de base sont donc des données
qui ne changent pas pendant une longue période (paramètres, données sur les clients et produits).
Données de flux (ou transactionnelles): données présentant une certaine dynamique avec un caractère temporel (par ex-
emple assorties d’une date de validité). Les données transactionnelles sont sans cesse renouvelées par les processus opé-
rationnels de l’entreprise et sont généralement utilisées par une seule application ou par un petit nombre d’applications.
Remarque: la classification dans l’une ou l’autre catégorie n’est pas toujours évidente et dépend fortement du contexte. Les
données de base dans une application ou une base de données (par ex. données sur les articles dans un système de gestion
des stocks) peuvent être des données transactionnelles dans une autre base de données (par ex. données sur les articles
dans une application servant à la création d’un catalogue de produits centralisé au sein d’un même groupe).
Eléments probants
Informations dont l’auditeur tire des conclusions et sur lesquelles repose son opinion d’audit. Elles comprennent des do-
cuments et enregistrements comptables comme base des états financiers ainsi que des informations d’autres sources les
corroborant.
Environnement de contrôle
Attitude générale, prise de conscience et action de la direction de l’entreprise en relation avec le contrôle interne et sa
signification pour l’entreprise. Influence l’efficacité des contrôles internes individuels.
ERP
ERP signifie «Enterprise Resource Planning». L’objectif des systèmes ERP est d’intégrer de bout en bout l’ensemble des
processus métier dans un système centralisé. Les domaines d’utilisation typiques des logiciels ERP sont la finance et la
comptabilité, la gestion du matériel, la production, la vente, le marketing, etc. ainsi que la gestion des données de base y
relatives. La capacité de paramétrisation des systèmes ERP standards, permet dans la pratique d’adapter les caractéristiques
de fonctionnement aux exigences de chaque entreprise.
Examen succinct …: voir Review / Examen succinct
Interfaces
Une interface est un élément de système servant à la communication, à l’échange d’informations entre différents compo-
sants et sous-systèmes. Une interface est définie par un nombre de règles.
Dans le cas d’interfaces de données, l’échange a lieu sous forme de données logiques, par ex. via des fichiers ou des
enregistrements de données.
41
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Les interfaces entres logiciels (interfaces externes) et les points d’intégration entre différents modules (interfaces internes)
sont des points de contact logiques dans un système informatique. Elles définissent les modalités d’échange des com-
mandes et des données entre les différents processus et composants du système (par ex. accès aux routines système, autres
processus, composantes logicielles, etc.).
Objectif de contrôle
Un objectif de contrôle est une expression du résultat souhaité (but) devant être atteint grâce à la mise en place de (procé-
dures de) contrôles dans un domaine d’activité.
Paramètre
Par paramètre, on entend en informatique un argument transmis à un programme ou à un sous-programme (donnée de
pilotage externe).
Patch (correctif)
Un patch est un correctif pour un logiciel ou pour des données du point de vue de l’utilisateur final destiné à corriger des
failles de sécurité ou à installer de nouvelles fonctionnalités. Souvent, un patch constitue une solution temporaire en at-
tendant que le problème soit réglé. Comme les patches ne sont pas soumis à des procédures de test aussi rigoureuses que
celles des programmes à proprement parler, ils peuvent être à l’origine de nouvelles déficiences et problèmes de sécurité
dans les applications.
Principes généraux de l’audit ou des services connexes; généraux…
Principes régissant l’exercice responsable de la profession d’auditeur ou d’expert-comptable:
• Indépendance (dans le cas d’un audit ou d’une review);
• Intégrité;
•Objectivité;
•Compétence professionnelle et diligence;
•Discrétion;
•Comportement professionnel;
• Respect des prescriptions et des normes légales.
Procédures analytiques: voir Procédures d’audit; analytiques…
Procédures d’audit; analytiques…
Procédures visant à obtenir des éléments probants (souvent analyses de données assistées par un outil informatique). Ces
procédures sont utilisées dans le cadre des analyses de tendances et de chiffres clés mais également lors de l’examen des
modifications et des relations qui diffèrent d’autres informations pertinentes ou de montants faisant l’objet de prévisions.
Procédures d’audit; orientées résultat
Procédures d’audit permettant d’obtenir des éléments probants pour identifier des anomalies significatives dans les états
financiers. Il convient de distinguer entre les procédures de vérification de détail et de vérification analytiques. Synonyme:
procédures d’audit substantives.
Procédures d’audit; orientées procédures ou risques
Procédures d’audit permettant d’obtenir des éléments probants sur l’adéquation de la conception et de l’efficacité du fon-
ctionnement du système comptable et des contrôles internes.
42
Rapport de gestion
Document établi chaque année et comportant les états financiers audités ainsi que le rapport de l’auditeur (et, le cas
échéant, d’autres informations). Juridiquement, le rapport de l’organe de révision ou du réviseur des comptes consolidés
ne fait pas partie du rapport de gestion.
Release
La version aboutie et publiée d’un logiciel est appelée release. Toutes les modifications d’une release à une autre sont habi-
tuellement saisies systématiquement dans l’outil de gestion de version ou de configuration datées (horodatage) et assorties
de la référence utilisateur. Il est important que tous les utilisateurs utilisent la même version de logiciel et que l’auditeur
puisse identifier tout changement de release.
Reproductibilité
Les informations traitées dans un système d’information et les opérations effectuées par le système sont rétroactivement
contrôlables et vérifiables.
Review / Examen succinct
Le but d’un examen succinct (Review) des états financiers consiste à indiquer si l’auditeur a rencontré des éléments le con-
traignant à conclure que les états financiers ne concordent pas, à tous les égards importants, avec les normes de présen-
tation des comptes applicables. L’auditeur fait cette assertion sur la base de procédures d’audit qui ne livrent pas tous les
éléments probants exigés par un audit (éléments probants). La review d’informations financières ou d’autres informations
élaborées selon des critères appropriés poursuit un objectif comparable.
Rotation
Par principe de rotation, on entend habituellement le principe d’audit qui consiste à ne pas vérifier chaque année l’ensemble
des contrôles clés mais à procéder, sur la base du jugement de l’auditeur, à un minimum de vérifications de contrôles clés
au cours d’une année et dans certains domaines. Il faut toutefois s’assurer que l’ensemble des contrôles clés sont pris en
compte dans l’audit au cours d’un cycle de planification défini par l’auditeur en fonction de la situation des risques (géné-
ralement 3 ans).
SaaS: voir Software as a Service.
SAS 70
Statement on Auditing Standards (SAS) No. 70, Service Organizations, est une norme d’audit reconnue internationalement
et développée par le American Institute of Certified Public Accountants (AICPA). SAS 70 est une norme permettant aux or-
ganisations de services de présenter leurs activités et leur processus de contrôles à leurs clients et aux auditeurs dans un for-
mat de rapport standardisé. Elle permet aux organisations de services, lorsqu’elles hébergent ou traitent des données et des
processus opérationnels de clients, de prouver qu’elles ont implémenté des contrôles et des mesures de sécurité adaptés.
Software as a Service (SaaS)
Méthode de mise à disposition d’un logiciel (à la demande) via Internet. Semblable à Application Service Provider (ASP). Par
rapport au modèle ASP, SaaS est davantage conçu pour l’intégration d’autres procédures / applications et peut ainsi mieux
supporter une architecture orientée service (SOA).
Sondage: voir Test de cheminement
43
GUIDE D’AUDIT DES APPL ICAT IONS INFORMATIQUES
Système de contrôle; interne…
Définition selon la norme d’audit NAS 890: Le SCI au sens de la nouvelle norme d’audit comprend uniquement les processus
et les mesures dans une entreprise qui garantissent une tenue régulière de la comptabilité et des rapports financiers. Le
SCI est constitué, selon la définition communément admise, de «composantes de contrôle» (environnement de contrôle,
processus d’évaluation des risques de l’entreprise, systèmes d’information / de communication importants pour la tenue de
la comptabilité et l’établissement des comptes) d’activités de contrôle et de surveillance des contrôles. Dans des situations
simples, ces composantes de contrôle présentent souvent des caractéristiques différenciées ou peuvent également être
regroupées.
Définition au sens large: ensemble des principes et des procédures (contrôles internes) définis par la direction en vue de
garantir la conformité et l’efficacité des traitements opérationnels (incluant les prises en compte des principes définis par
la direction de l’entreprise), la sécurité des actifs, la prévention ou l’identification de fraudes et d’erreurs, l’exactitude et
l’exhaustivité des enregistrements comptables ainsi que l’élaboration d’informations financières fiables et utilisables, en
temps utile.
Test de cheminement
Un test de cheminement désigne l’analyse systématique (reconstruction) d’un processus et sert à comprendre et à vérifier
ce dernier. Lors de cette vérification, l’auditeur suit les chemins à travers le processus définis par les conditions préalables et,
le cas échéant, par les décisions prises par l’utilisateur.
Test de non-régression
Répétition d’un test qui a déjà été entièrement réalisé, par ex. dans le cadre de travaux d’entretien, de modification et de
correction, le test de non-régression permet de faciliter l’analyse des résultats du test par comparaison avec les résultats du
test précédant.
44