Infrastructu re IT Systèmes
IT Applications Processus méti er
© ITACS Trainin
g
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)
informatiques
Une approche inspirée des audits financiers
Novembre 2008
Guide d’audit des
applications informatiques
Novembre 2008
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
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
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
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 globale Evaluation
du fonctionn
ement du contrôle Evaluation de la conceptio
n 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 interfac
es Identification des processus opér
ationnels
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:
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
non couvert par la méthodecouvert par la méthode Processus métier / tran
sactions
Applicatio
ns financières
Middlewar
e / base de do nnées
Systèmes d’exploitatio n / 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.
Vue d’ensemble
Procédure
Infrastructure IT
© ITA CS Traini
ng
© 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 comptes
par 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
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
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.».
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
Inventaire Equipements Créditeurs
422’234 57’000 121’000 45’000
Paiements Achat Commandes
Frais de personnel Assurances
121’111 13’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
manag e- Purcha- ment
sing
Sales
Controlling Accounti
ng
Strategic purchasing
Operating purchasing
Vendor Goods
recept
Invoice vertificatio
n
Accounts payable MRP
Inventory accounting Warehouse
Assets accounting Work
scheduling
Engineering
Job preparation
Production
Internal accounting
GL accounting
Overhead cost management Inventory
accounting
Billing Warehouse
Shopping Custom
er MRP
Accounts receivable Operative
sales Strategic
sales
Raw materials
Finished production Materials
manage-ment
Exemple B
Présentation graphique (forme de flux de traitement des données). En cas d’analyse d’interactions complexes.
Marché Marché
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
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.
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
© ITA CS Traini
ng
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
EXCEL
FACTURE
COMPTA
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.
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
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
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).
4 Identification des risques et des contrôles clés
= Risques
= Contrôle
Infrastructure IT Systèmes IT Applications Processus métier
© ITA CS Traini
ng
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?
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érationnelle Contrôle Authenticité Evaluation Délimitation période Droits et obligations Imputation Comptabilisation Autorisation Principe du justificatif Historisation Conservation Auditabilité Préventif Détectif
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?
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
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?
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
Présentation des informations
La documentation du test de cheminement, durant lequel les étapes manuelles ou automatiques du processus ou de la classe de transaction sont vérifiées, est normalement élaborée sur la base de descriptions, diagrammes de flux, de copies d’écran, de documents, etc.
Particularités
Dans la pratique, le test de cheminement s’accompagne souvent de l’évaluation de la conception du contrôle et, dans le cas de contrôles automatiques, également de l’évaluation du fonctionnement des contrôles. Dans la présente approche d’audit, ces deux étapes constituent la suite logique du test de cheminement et sont traitées séparément dans les deux chapitres suivants.
Les tests de cheminement sont souvent divisés en plusieurs parties. C’est pourquoi, au cours du déroulement des sous- processus ou des applications individuelles, les interfaces qui les relient sont souvent oubliées.
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.
6 Evaluation de la conception des contrôles
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.
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.
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é.
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.
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
• 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.
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
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
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.
