Guide d audit des applications informatiques

Guide d audit des applications informatiques Une approche inspirée des audits financiers Novembre 2008 Processus métier Applications Systèmes IT Infrastructure IT 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 Guide d audit des applications informatiques Novembre 2008 1

Cet ouvrage est le fruit des réflexions et des expériences des membres de la Commission informatique de la Chambre fiduciaire 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 2

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Table des matières Table des matières 3 Présentation générale et introduction 4 Analyse du bilan et du compte de résultats 7 Identification des processus métier et des flux de traitement des données 9 Identification des applications de base et des principales interfaces IT pertinentes 13 Identification des risques et des contrôles clés 18 Tests de cheminement 22 Evaluation de la conception des contrôles 24 Evaluation du fonctionnement des contrôles 28 Appréciation globale 32 Annexe 1 - Contrôles liés aux applications 36 Annexe 2 - Glossaire 38 3

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 domaines 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 processus, une méthode de vérification et une approche intégrée de l audit des contrô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 financiers. 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. 4

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Les 8 étapes de la méthode de vérification: 1 2 3 4 5 6 7 8 Analyse du bilan et du compte de résultats Identification des processus opérationnels et flux de données Identification des applications clés et interfaces Identification des risques et contrôles clés Test de cheminement Evaluation de la conception du contrôle Evaluation du fonctionnement du contrôle Appréciation globale 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 financiers 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étermine les flux de traitement des données à l origine des principales 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 simplifié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. 5

Délimitation de l approche de contrôle couvert par la méthode non couvert par la méthode 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 Processus métier / transactions Applications financières Middleware / base de données Systèmes d exploitation / réseau Contrôles d applications IT Intégralité Exactitude Validité Autorisation Séparation des fonctions 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. 6

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 1 Analyse du bilan et du compte de résultats Vue d ensemble Contenu et objectif Contexte 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 transaction 1 à l origine de ces positions. L analyse 2 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 importantes 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érification 2 utilisées. Procédure Principaux comptes par ex. débiteurs RISQUE RISQUE Assertions dans les états financiers, par ex.: Processus métier Applications Systèmes IT Infrastructure IT ITACS Training RISQUE RISQUE Authenticité Évaluation Intégralité Droits et obligations 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 7

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érations à 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 commerciales 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.» 8

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 2 Identification des processus métier et des flux de traitement des données Vue d ensemble Contenu et objectif Contexte Identification des processus métiers significatifs qui sont à l origine des transactions et classes de transactions 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és 4. 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, limité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. 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 graphique. 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 documentation 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. 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.». 9

Présentation sous forme de tableau. solution adaptée à des éléments comptables et interactions simples. 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 Frais de personnel Assurances 422 234 57 000 121 000 45 000 121 111 13 000 Paiements Achat Commandes Paiements Gestion ressources humaines Etc Contrats, services Immobilisation 121 000 Amortissement Bouclement Valeur Divers Positions consolidées Consolidation Positions d une filiale Présentation sous forme de graphique (forme de flux de traitement) - solution adaptée à des interactions complexes Exemple A Sales Materials management Purchasing Strategic purchasing Operating purchasing Vendor Raw materials Goods recept MRP Production Work scheduling Engineering Warehouse Job preparation Inventory accounting Materials management Finished production Production Internal accounting MRP Strategic sales Operative sales Warehouse Shopping Customer Billing Inventory accounting Accounts receivable Invoice vertification GL accounting Accounting Controlling Assets accounting Overhead cost management Accounts payable 10

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Exemple B Corporate Governance Processus de pilotage Processus de définition des objectifs Contrôle de gestion Stratégie Organisation d entreprise Gestion du personnel Category Management (CM) Acquisition (achat/dispatching) Marché Logistique Marché Vente Processus de support Finances/Services Informatique Personnel/formation Communication Gestion de la qualité Gestion immobilière Gestion des emplacements Services internes Production Présentation graphique (forme de flux de traitement des données). En cas d analyse d interactions complexes. 11

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. Exemples Le processus d achat est composé des sous-processus gestion des données de base fournisseurs, facturation fournisseurs et comptabilisation des achats. Le processus de vente est composé des sous-processus gestion des données de base clients, facturation clients et comptabilisation 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. 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 paramè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. 12

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 3 Identification des applications de base et des principales interfaces IT pertinentes Vue d ensemble Contenu et objectif Identification des applications IT concernées et de leurs interfaces Processus métier Applications Systèmes IT Infrastructure IT ITACS Training 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 impossibilité 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 programme d audit. 13

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 SALAIRE COMPTA EXCEL FACTURE 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 14

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Applications standard Les applications standard au bénéfice d une certaine maturité présentent généralement une multitude de contrôles intégrés pertinents. Le tableau ci-après montre, à titre d exemple, quelques contrôles de base destinés à assurer l intégrité des transactions traitées: Une application de comptabilité standard devrait disposer des fonctionnalités suivantes (liste non exhaustive) Datation automatique des opération et des transactions par le système Offrir plusieurs identifications utilisateurs avec des mécanismes d authentification Ces fonctionnalités offrent (ou impliquent) les contrôles suivants Protection de l accès aux paramètres de la date système 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 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.) Interdiction de supprimer Mécanisme de protection d accès par des profils de groupe ou des autorisations individuelles. Enregistrement automatique des anciennes valeurs dans un fichier historique (avec date de validité: valable dès le / jusqu au, date de la mutation et identification de l utilisateur qui a effectué la modification) Protection des accès aux paramètres et au fichier historique. Le programme ne doit pas proposer de fonction de suppression des donné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 électronique, 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 connaissance suffisante sur les sources d erreur connues). l auditeur dispose-t-il de connaissances et d expériences personnelles relatives à l application? 15

Les réponses servent, conformément à la norme NAS 310 chiffre 10, à «l identification des domaines requérant une attention 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 à disposition 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 systè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 interne 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. 16

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Utilisation centralisée ou décentralisée de l application De même, en raison des responsabilités déléguées mais également d une complexité technique souvent considérable (par ex. en termes d intégrité liée à des procédures de sauvegardes redondantes des données ou des séquences de traitement au travers de plusieurs périodes ou zones temporelles différentes), l utilisation décentralisée d une application comporte des risques inhérents et des risques d audit supplémentaires qui augmentent la complexité de l audit. Représentation des informations Représentation sous forme de tableau 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 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 risque. Il est important de les identifier et de les contrôler. Nom de l interface Type Applications en amont/aval Type de flux Fréquence Listes d erreur Evaluation des risques 17

4 Identification des risques et des contrôles clés 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 notamment à 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 également analysé (par ex. exhaustivité, authenticité, évaluation, rattachement à l exercice ou représentation dans les comptes annuels). Processus métier Applications Systèmes IT Infrastructure IT = Risques = Contrôle ITACS Training 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émentés et la couverture des risques est évaluée. 18

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Procédure Risques, objectifs de contrôle et contrôles Au sein des principaux processus et des systèmes impliqués, les risques qui peuvent entraîner une inexactitude importante dans les états financiers sont identifiés. Le résultat obtenu est un aperçu des risques susceptibles d empêcher la réalisation des objectifs du processus. Cette analyse des risques permet également de définir l étendue des procédures d audit. Les objectifs de contrôle découlent des risques. Un objectif de contrôle est défini comme une assertion relative au résultat souhaité (but) devant être atteint grâce à l implémentation du contrôle. Les objectifs de contrôle sont donc souvent des risques «inversés», autrement dit, ils visent la diminution d un risque donné. Par la suite, l auditeur définit les attentes relatives aux contrôles typiques et attendus pour les risques identifiés. Il convient de subdiviser ces contrôles en «contrôles clés» et autres contrôles. Les contrôles clés, individuels ou combinés entre eux, sont indispensables à une réduction acceptable des risques. Ils sont donc garants de la fiabilité des résultats du processus et des données financières. Les contrôles clés constituent «la colonne vertébrale» du système de contrôle et sont donc des objets de vérification essentiels. Les autres contrôles ont une pertinence moindre pour l auditeur. Les contrôles clés attendus par l auditeur sont comparés aux contrôles effectivement mis en place et la couverture des risques 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? 19

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 contrôles 5 : Impact Qu estce qui pourrait se passer? Qui contrôle quoi, comment? Assertions dans les états financiers 6 Risques Contrôles Activité 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 Conception des contôles Le contrôle est-il capable de remplir les critères? Efficacité des contrôles Fonctionnement des contôles Les contrôles sontils réalisés? Efficacité Oui / non / n.a. Un élément supplémentaire au centre de cette matrice des risques et des contrôles permet d indiquer l assertion 6 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. 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. 20

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Concentration sur les contrôles clés Si l auditeur ne se concentre pas sur les contrôles clés, l audit risque d être trop général et inefficace. De même, une description 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 conformé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 commande, 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 21

5 Tests de cheminement Vue d ensemble 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 (financiers) 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. 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 traitements des erreurs. Questions devant être prises en compte durant le test de cheminement du processus: à qui faire appel pour obtenir des explications sur les 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? 22

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Présentation des informations La documentation du test de cheminement, durant lequel les étapes manuelles ou automatiques du processus ou de la classe de transaction sont vérifiées, est normalement élaborée sur la base de descriptions, diagrammes de flux, de copies d écran, de documents, etc. Particularités Dans la pratique, le test de cheminement s accompagne souvent de l évaluation de la conception du contrôle et, dans le cas de contrôles automatiques, également de l évaluation du fonctionnement des contrôles. Dans la présente approche d audit, ces deux étapes constituent la suite logique du test de cheminement et sont traitées séparément dans les deux chapitres suivants. Les tests de cheminement sont souvent divisés en plusieurs parties. C est pourquoi, au cours du déroulement des sousprocessus ou des applications individuelles, les interfaces qui les relient sont souvent oubliées. 23

6 Evaluation de la conception des contrôles Vue d ensemble 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 (couverture 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 niveau 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 fonctionnement (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. 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 raisonnable 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. 7 PS 400: Evaluation des risques et contrôle interne RZ27. 24

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Procédures d audit Les procédures d audit d évaluation de la conception des contrôles comportent des questions, des observations, des tests de cheminement, la revue de la documentation principale et l évaluation de l adéquation de contrôles spécifiques. L auditeur forme son opinion sur la conception des contrôles en: interrogeant les membres de la direction de l entreprise et les collaborateurs ayant des tâches de surveillance ainsi que les collaborateurs impliqués dans la réalisation du contrôle; consultant les documents relatifs aux transactions et les autres documents importants de l entreprise; observant les activités spécifiques d exécution et de contrôle; suivant les transactions individuelles dans le système d information (test de cheminement). Conformément aux normes d audit en vigueur, les procédures d audit d évaluation de la conception des contrôles «Design Effectiveness» doivent être documentées par des éléments probants (évidences d audit). Questions relatives à l évaluation de la conception des contrôles L interrogation des collaborateurs du domaine contrôlé à l aide de quelques questions types, permet parfois sous forme d un processus itératif d identifier des faiblesses importantes dans la structure du contrôle 8. 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 automatiques? Les contrôles en aval, c est-à-dire détectifs, sont-ils remplacés, quand cela est possible, par des contrôles en amont, autrement 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 financiè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. 25

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 controls 9 ) ou ne sont pas redondants. Les contrôles en amont, c est-à-dire les contrôles préventifs, mais également les contrôles automatiques 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 potentiel 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 redondante 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 conformité 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]. 26

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Contrôles clés inopérants Dans le cadre de son appréciation de la conception des contrôles, lorsque l auditeur identifie des contrôles clés qu il considè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é. 27

7 Evaluation du fonctionnement des contrôles Vue d ensemble 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ée 10. 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écoulent de la stratégie d audit. 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. 10 Grant Thornton 2007, p. 5. 11 NAS 500 Éléments probants de contrôle, RZ 19 ss. 28

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Baselining / Benchmarking: l objectif de cette stratégie est de réduire l étendue des travaux de contrôles durant les périodes d audit suivantes. Pour ce faire, les résultats des tests d un contrôle d application sont repris dans les périodes de contrôle suivantes. Les tests réalisés durant la première période d audit servent d ancrage. S il est attesté qu aucune modification n a été apportée au contrôle d application dans la période suivante et que les contrôles IT généraux pertinents ont été testés avec succès, l efficacité des contrôles d application est considérée comme effective et ne fait pas l objet de nouveaux tests. A intervalles réguliers, le contrôle doit toutefois faire l objet d un nouvel ancrage. Cette stratégie de test est applicable lorsque par ex. un contrôle d application dépend clairement d une configuration ou si les éventuelles modifications sont clairement visibles. La stratégie ne devrait pas être appliquée lorsque le nombre de modifications apportées au système est élevé, et ce, en raison des effets secondaires possibles et en cas de contrôles IT généraux instables. Analyse des données: l efficacité d un contrôle est vérifiée au moyen d une analyse des données assistée par ordinateur. Dans le cas idéal l analyse porte sur l ensemble des données pertinentes. Test de contrôles contre test de transactions end-to-end Aujourd hui, la plupart des auditeurs identifient les contrôles dans le cadre du flux de transactions puis testent et évaluent leur efficacité sous forme de contrôles ponctuels. Cette procédure ne correspond toutefois pas à l approche choisie généralement lors de l implémentation des applications. L objectif visé est de contrôler les fonctionnalités de l application au moyen de jeux de tests complets. Les jeux de tests sont conçus pour toutes les opérations commerciales significatives et sont réalisés de bout en bout à l aide de l application. En pareilles situations, il devrait être possible de réaliser des synergies considérables lorsque l auditeur est associé à la définition des jeux de tests et a la possibilité de contribuer à la conception des tests couvrant non seulement la fonctionnalité opérationnelle mais également la fonctionnalité souhaitée des contrôles clés. Cette procédure peut également constituer un ancrage pour une approche de tests ultérieure dite «Baselining». Tests de non-régression Par test de non-régression, on désigne la répétition de l ensemble ou d une partie des jeux de tests afin de détecter d éventuels effets secondaires liés aux modifications des parties déjà testées d une application. Ces modifications surviennent 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. 29

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 manuels. Le choix d un contrôle par échantillonnage à partir d une population de cas à tester est judicieux lorsque cette population 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: 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 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 auditeur 12 : 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 changements 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 surviennent 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. 12 Ernst&Young, Evaluating Internal Controls. p. 10. 30

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Influence de la taille de l entreprise Selon la norme d audit NAS 400, l auditeur doit obtenir le même degré d assurance indépendamment de la taille de l entreprise; toutefois, il peut tenir compte du fait que certains contrôles internes ne sont pas praticables pour de petites entreprises ou de petites unités d organisation. Ainsi, une séparation des fonctions insuffisante (Segregation of Duties) peut être remplacée par un contrôle direct fort du management (contrôle compensatoire), ou l auditeur peut compenser l absence d évidences de contrôle ou d éléments probants par des contrôles orientés résultat (stratégie de contrôle adaptée). La NAS 400 définit également les limites du contrôle interne que l auditeur doit prendre en compte lors de son évaluation. 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. 31

8 Appréciation globale Vue d ensemble Contenu et objectif Contexte 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. 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. 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écessitent 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. 32

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Présentation des informations L auditeur établit à l intention de la direction, outre son opinion d audit, une synthèse de la situation des risques au niveau des processus et des applications contrôlés. Particularités Les exceptions identifiées lors de l évaluation des contrôles clés et non corrigées par des contrôles compensatoires doivent être évaluées, par définition, de manière plus critique que les déficiences des autres contrôles. 33

Annexe 1 - Contrôles liés aux applications 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 également 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 commerciale. 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 34

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 1 Création et autorisation Les principaux objectifs relatifs à la création et à l autorisation sont les suivants: minimiser les erreurs et les omissions identifier, documenter, communiquer et corriger les erreurs et les irrégularités dès leur apparition vérifier l exactitude de la correction des erreurs par un service / une personne indépendante les opérations commerciales (transactions) ne sont effectuées que par des personnes habilitées et / ou selon des procédures autorisées les personnes responsables de la saisie des transactions commerciales sont identifiées dans le système les justificatifs de saisie délivrés sont exhaustifs et exacts et sont transmis en temps utile les justificatifs de saisie sont conservés pendant la période légale et sous la forme prescrite ou peuvent être reconstitués par l organisation. Les contrôles typiques concernant la création et l autorisation sont les suivants: profils des compétences pour l établissement de pièces comptables (par ex. règlement sur les signatures) et mise en œuvre au travers un contrôle des autorisations par des systèmes de gestion des accès séparation des fonctions de création et de validation de pièces comptables visa ou signature sur les justificatifs de saisie formulaires de saisie compréhensibles et utiles (par ex. avec des champs préimprimés) processus d identification précoce et de traitement des erreurs et des irrégularités collecte systématique des pièces comptables (par ex. dans l ordre chronologique à l aide d un horodateur ou séquentiellement à 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) 35

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 à nouveaux 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. 36

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 4 Sortie de données (output) Les principaux objectifs de la sortie des données sont les suivants: la sortie des données s effectue en temps utile, au bon endroit et conformément aux procédures définies l exhaustivité et l exactitude des informations éditées sont garanties par des procédures effectuées de manière systématique 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, voicemail, 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 également ê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 application. Ces derniers ne seront pas détaillés dans ce document. 37

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 bureautiques, 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 publié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 affecté à 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. 38

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Benchmarking: voir Baselining Business Rule Terme technique désignant les règles de gestion devant être prises en compte dans les spécifications de l application, son développement, les tests et la livraison compte tenu de l impact important qu elles peuvent avoir, en tant qu exigences de contrôles clé, sur la conception du SCI. Caractère significatif Des informations ont un caractère significatif lorsque leur omission ou leur présentation erronée pourrait influencer des décisions économiques des destinataires prises sur la base des états financiers. Le caractère significatif dépend de la taille du poste ou de l erreur résultant de circonstances particulières de l omission ou de la présentation erronée. Le caractère significatif est plutôt un seuil ou une valeur limite et moins une exigence qualitative première que doit avoir une information pour pouvoir être utile. Contrôles Les contrôles sont des concepts, des procédures, des pratiques et des structures d organisation permettant de vérifier avec une assurance raisonnable la réalisation des objectifs d entreprise et la prévention ou l identification et la correction d événements non désirables. On distingue entre autres: Contrôles applicatifs Les contrôles applicatifs sont des contrôles intégrés aux applications. Les objectifs des contrôles applicatifs portent sur des applications spécifiques. Les contrôles typiques portent sur l exhaustivité et l exactitude des saisies et des traitements, sur la validité des saisies, etc. Contrôles IT généraux Les contrôles IT généraux constituent la base pour un fonctionnement en bonne et due forme des contrôles applicatifs automatisés. Les contrôles IT généraux couvrent les risques inhérents aux droits d accès, à la qualité et à la sécurité des données ou à la maintenance et aux changements des systèmes (matériel et logiciel). Contrôles hybrides Combinaison de contrôles manuels et automatiques Contrôles compensatoires Contrôles internes qui réduisent le risque d une faiblesse existante ou potentielle susceptible d occasionner une erreur ou une omission. Direction de l entreprise Personnes responsables de la surveillance, de la haute direction et du contrôle (Gouvernance) d une entreprise (par ex. le conseil d administration d une SA). Cette notion est utilisée dans les cas où l on ne peut pas faire la distinction entre, d une part, les responsables de la gestion et du contrôle et, d autre part, la direction des affaires. 39

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 exemple 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 documents 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 composants 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. 40

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Les interfaces entres logiciels (interfaces externes) et les points d intégration entre différents modules (interfaces internes) sont des points de contact logiques dans un système informatique. Elles définissent les modalités d échange des commandes 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 attendant 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 fonctionnement du système comptable et des contrôles internes. 41

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 habituellement 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 contraignant à conclure que les états financiers ne concordent pas, à tous les égards importants, avec les normes de présentation 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 organisations de services de présenter leurs activités et leur processus de contrôles à leurs clients et aux auditeurs dans un format 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 42

GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Système de contrôle; interne Définition selon la norme d audit NAS 890: Le SCI au sens de la nouvelle norme d audit comprend uniquement les processus et les mesures dans une entreprise qui garantissent une tenue régulière de la comptabilité et des rapports financiers. Le SCI est constitué, selon la définition communément admise, de «composantes de contrôle» (environnement de contrôle, processus d évaluation des risques de l entreprise, systèmes d information / de communication importants pour la tenue de la comptabilité et l établissement des comptes) d activités de contrôle et de surveillance des contrôles. Dans des situations simples, ces composantes de contrôle présentent souvent des caractéristiques différenciées ou peuvent également être regroupées. Définition au sens large: ensemble des principes et des procédures (contrôles internes) définis par la direction en vue de garantir la conformité et l efficacité des traitements opérationnels (incluant les prises en compte des principes définis par la direction de l entreprise), la sécurité des actifs, la prévention ou l identification de fraudes et d erreurs, l exactitude et l exhaustivité des enregistrements comptables ainsi que l élaboration d informations financières fiables et utilisables, en temps utile. Test de cheminement Un test de cheminement désigne l analyse systématique (reconstruction) d un processus et sert à comprendre et à vérifier ce dernier. Lors de cette vérification, l auditeur suit les chemins à travers le processus définis par les conditions préalables et, le cas échéant, par les décisions prises par l utilisateur. Test de non-régression Répétition d un test qui a déjà été entièrement réalisé, par ex. dans le cadre de travaux d entretien, de modification et de correction, le test de non-régression permet de faciliter l analyse des résultats du test par comparaison avec les résultats du test précédant. 43

44