guide d'audit des applications informatiques

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


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


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


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


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


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


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


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


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


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


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



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


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


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


• 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


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



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


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


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


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


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


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.

guide d'audit des applications informatiques

Documents