4028.4 Tests des dépendances aux TI avec ou sans un appui sur les contrôles généraux informatiques

sept.-2022

Directives du BVG

Introduction

Chez de nombreuses entités, une grande partie de l’information utilisée pour les activités au sein du processus de suivi du système de contrôle interne et des autres contrôles manuels et automatisés sera générée par le système d’information de l’entité. Toute erreur ou omission dans l’information pourrait rendre ces contrôles inefficaces.

De plus, lorsqu’il met en œuvre des procédures de corroboration, l’auditeur utilise souvent de l’information générée par les applications informatiques d’une entité. Si cette information est inexacte ou incomplète, les éléments probants pourraient aussi être inexacts ou incomplets.

Pour ces raisons, le plan d’audit comprend des procédures visant à traiter la fiabilité de l’information utilisée :

• Dans le fonctionnement des contrôles utiles auxquels l’auditeur a l’intention de se fier, et/ou
• Comme base de nos procédures de test de corroboration, y compris les procédures analytiques de corroboration et les tests de détail

L’auditeur doit acquérir une compréhension des sources d’information que la direction utilise et déterminer la nature et l’étendue des tests de la fiabilité de cette information.

La détermination de la nature et de l’étendue des éléments probants nécessaires pour évaluer la fiabilité de l’information utilisée aux fins de l’audit relève du jugement professionnel, lequel est modulé par les éléments suivants :

• le niveau d’éléments probants recherché de la procédure de test des contrôles ou de corroboration;
• le risque d’anomalies significatives associé aux postes des états financiers en cause;
• la mesure dans laquelle l’efficacité du contrôle ou la conception du test de corroboration dépend de l’exhaustivité et de l’exactitude de l’information;
• la nature, la source et la complexité de l’information, y compris la mesure dans laquelle la fiabilité de l’information dépend d’autres contrôles (contrôles du traitement de l’information manuels ou automatisés et/ou CGI);
• les connaissances acquises lors d’audits antérieurs qui sont pertinentes pour l’évaluation (c.‑à‑d. les déficiences de contrôle des exercices antérieurs, les changements marquant l’environnement de contrôle ou d’autres risques évalués).

Autres facteurs à considérer : la complexité de l’application et le type de l’information, comme le montre le graphique suivant :

Éléments probants nécessaires moins persuasifs	Facteur	Éléments probants nécessaires plus persuasifs
Application non complexe	Complexité de l’application	Application complexe
Rapport type	Type de rapport	Requête ponctuelle
Recherche d’un faible niveau d’éléments probants à partir des tests	Manière dont le rapport est utilisé aux fins de l’audit	Recherche d’un niveau élevé d’éléments probants à partir des tests

Compréhension de la nature et de la source de l’information sous-jacente

Afin de planifier l’approche qu’il utilisera pour évaluer la fiabilité de l’information sous-jacente utilisée dans l’audit, l’auditeur doit d’abord considérer la nature, la source et la complexité de l’information elle-même. L’auditeur utilise généralement l’information générée par une application informatique sous la forme de rapport (appelé aussi « rapport généré par le système »). Ces types de rapport sont notamment :

Type de rapport	Description
Rapport type	Un rapport conçu par un développeur de logiciel de l’extérieur qui ne peut être ni modifié ni personnalisé par l’entité — Ces rapports arrivent préconfigurés et/ou prédéfinis dans des progiciels bien établis. De nombreuses applications, dont SAP et JD Edwards, fournissent des rapports types, tels que des rapports chronologiques des créances, indépendamment du type d’entité.
Rapport personnalisé	Un rapport type modifié ou un rapport développé pour répondre au besoin spécifique de l’utilisateur — Les rapports personnalisés permettent à une entité de concevoir l’information à y inclure et la manière de la présenter. Par exemple, dans un rapport personnalisé, la direction pourrait modifier un rapport chronologique des créances type pour montrer le classement chronologique par client plutôt que par facture. Les rapports générés par une application maison (développé par l’entité) sont des rapports personnalisés. Généralement, les utilisateurs finaux de l’entité ne sont pas capables de créer ou de modifier des rapports personnalisés, la personnalisation devant être faite la plupart du temps par le fournisseur ou l’administrateur de l’application.
Requête	Un rapport généré de manière ponctuelle ou récurrente permettant aux utilisateurs de définir une série de critères à partir desquels le système produira les résultats qu’ils recherchent — Ce type de rapports est souvent utilisé lorsque l’information recherchée concerne un élément, une opération ou un groupe d’éléments ou d’opérations défini par l’utilisateur. Par exemple, une requête pourrait servir à générer une liste de toutes les écritures de journal pour une unité opérationnelle en particulier. Des langages de requête (p. ex. SQL, SAS) peuvent être utilisés par des services des TI ou des utilisateurs chevronnés pour la conception de ces rapports. Une requête récurrente assujettie aux CGI pourrait avoir les mêmes caractéristiques qu’un rapport personnalisé; par exemple, une fois développée, testée et transférée en production, elle ne peut être modifiée que par son développeur. Des requêtes ad hoc (ponctuelles) sont généralement effectuées dans un but précis et ne seront probablement pas assujetties aux CGI. L’information générée par une application utilisée dans les tests de corroboration (p. ex. populations à échantillonner pour les tests de détail dans une procédure analytique désagrégée) pourrait être le résultat d’une requête ad hoc.

L’information générée par une application informatique peut aussi être extraite dans des formats modifiables (p. ex. feuilles de calcul). Voir la section BVG Audit 2051 au sujet des éléments à considérer concernant les feuilles de calcul et les autres formats modifiables tels que Microsoft Access.

Déterminer le type de rapport, y compris la distinction d’un rapport type, dépend des faits et circonstances propres à l’entité et nécessite l’exercice du jugement. Un spécialiste en audit informatique pourrait intervenir pour déterminer la nature des différents types de rapports à utiliser aux fins de l’audit. Par exemple, de nombreuses applications donnent la possibilité de générer des rapports personnalisés qui pourraient ressembler à des rapports types offerts dans l’application. L’auditeur doit faire la distinction entre les deux, car celle‑ci pourrait avoir un impact dans la détermination de la nature et l’étendue des procédures d’audit nécessaires pour tester la fiabilité de l’information fournie dans ces rapports.

Information générée par une application informatique – Approche de test – Exhaustivité et exactitude des données de base

Diagramme grandeur réelle

Tester l’efficacité du fonctionnement des contrôles du traitement de l’information est souvent une approche efficace et efficiente pour obtenir des éléments probants sur l’exhaustivité et l’exactitude des données de base. Un contrôle d’exhaustivité qui s’appuie sur l’utilisation de documents numérotés à l’avance est un exemple de contrôle du traitement de l’information. Au fil de la saisie des opérations, les numéros de documents absents ou en double sont repérés et inscrits dans un relevé des écarts, à des fins de suivi et de résolution.

Bien que les directives de la présente section mentionnent le test des « CGI et des contrôles du traitement de l’information », obtenir des éléments probants sur l’exhaustivité et l’exactitude des données de base peut aussi consister à rapprocher les données (p. ex. les opérations) aux documents sources et rapprocher les documents sources aux données, ou tester d’autres contrôles manuels pertinents appliqués aux données de base. Dans certains cas, l’exhaustivité et l’exactitude des données de base sous-jacentes seront testées dans le cadre des procédures d’audit visant un processus ou un compte en particulier. Ainsi, l’auditeur pourrait tirer profit des travaux d’audit déjà réalisés sur les données de base.

Lorsque l’approche de test pour les données de base prévoit le test de l’efficacité du fonctionnement des contrôles du traitement de l’information, l’auditeur doit déterminer s’il est approprié d’appliquer les directives qui se trouvent à la section BVG Audit 6056.

Les mentions de test des « CGI et des contrôles du traitement de l’information » dans les directives sont destinées à rappeler que, lorsqu’un auditeur teste l’exhaustivité et l’exactitude de l’information qui fera l’objet d’un rapport, il doit obtenir des éléments probants démontrant que les données de base sous-jacentes sont exhaustives et exactes. Le reste des directives sur les tests ci‑dessous ne visent pas l’exhaustivité et l’exactitude des données de base sous-jacentes, mais visent, plutôt, l’exhaustivité et l’exactitude des données de base présentées dans le rapport.

Information générée par une application informatique – Approche de test – Exhaustivité et exactitude des données de base présentées dans le rapport (logique de rapport)

Selon la nature de l’information du rapport qui sera utilisée, l’auditeur teste les attributs de rapport pertinents en suivant l’une des deux approches suivantes :

Tout d’abord, l’auditeur se demande si l’information générée par une application informatique :

1. sera utilisée comme base pour un test de détail de corroboration;
2. ne contient pas d’attributs sur lesquels l’auditeur s’appuie pour sélectionner les éléments à tester (sauf lorsque des valeurs monétaires sont utilisées pour une sélection fondée sur la couverture) tel qu’illustré dans les exemples et le graphique ci‑dessous.

Lorsque ces deux points s’appliquent, l’auditeur teste l’exactitude arithmétique de l’information et retrace les totaux générés par l’application avec ceux trouvés dans le grand livre général. Lorsqu’elles sont combinées aux tests de détails planifiés, ces procédures sont souvent suffisantes pour traiter l’exhaustivité et l’exactitude du rapport généré par le système.

Par exemple, lorsque l’auditeur planifie tester la corroboration des ajouts aux immobilisations corporelles en ciblant des éléments fondés sur la valeur monétaire sélectionnés dans un rapport généré par le système, il peut obtenir des éléments probants l’exhaustivité du rapport en testant l’exactitude arithmétique du rapport et en retraçant le total des ajouts du rapport avec les données du tableau des mouvements des immobilisations corporelles; en testant l’exactitude arithmétique du tableau des mouvements et en retraçant le total des immobilisations corporelles provenant du tableau des mouvements au grand livre général. L’auditeur obtiendrait ainsi des éléments probants de l’exactitude du rapport généré par le système en exécutant les tests de corroboration sur les ajouts sélectionnés (c.‑à‑d. que l’auditeur peut tirer profit de ces tests de corroboration pour traiter l’exactitude des ajouts inclus dans le rapport généré par le système).

L’approche de test décrite ci‑dessus pour l’information générée par le système qui répond aux conditions des points a) et b) pourrait aussi être appropriée lorsque l’auditeur ne teste pas les CGI ou détermine que les CGI ne fonctionnent pas efficacement.

Lorsque l’information générée par l’application informatique ne répond pas aux conditions décrites dans l’approche ci‑dessus (p. ex. un rapport détaillant les ajouts d’immobilisations corporelles par emplacement, où l’emplacement est pertinent à la conception du contrôle testé, ou comme base de sélection des éléments à corroborer dans un test ciblé fondé sur le risque), l’auditeur doit déterminer si le test des CGI et des contrôles d’application liés à l’application générant l’information soit efficient et/ou efficace.

1. Lorsque l’auditeur ne s’attend pas à ce que le test des CGI et des contrôles du traitement de l’information soit efficient et/ou efficace, en plus du test d’exactitude arithmétique de l’information et de la réconciliation du total de l’information au grand livre général (s’il y a lieu), il doit aussi exécuter les procédures de corroboration appropriées afin de tester l’exhaustivité et l’exactitude de l’information pour chaque occurrence de l’information qui est utilisée dans l’audit (voir la directive ci‑dessous sur la nature des tests à effectuer).
2. Lorsque l’auditeur s’attend à ce que le test des CGI et des contrôles du traitement de l’information soit efficient et/ou efficace, en plus de réconcilier le total de l’information au grand livre général (s’il y a lieu), il adopte l’une des approches suivantes pour traiter l’exhaustivité et l’exactitude de l’information :
   • Une approche d’analyse comparative (d’étalonnage), si possible (voir section G des directives sur l’arbre de décision ci‑dessous pour trouver une explication de l’approche et les circonstances où elle est appropriée);
   • Effectuer un test d’exactitude arithmétique, s’il y a lieu, et les tests de corroboration appropriés. Cette approche comprendra le test de corroboration d’au moins une occurrence, quel que soit le nombre des occurrences de l’information à utiliser aux fins de l’audit (voir section l des directives sur l’arbre de décision pour les approches de test de corroboration typiques).

L’illustration ci‑dessous résume les types de procédures de test qui pourraient s’appuyer sur des rapports générés par le système et les circonstances typiques où le test de fiabilité serait exécuté selon chaque approche (1 et 2).

Diagramme grandeur réelle

Test de l’information générée par une application informatique – Arbre de décision

Les approches de test décrites ci‑dessus sont illustrées dans l’arbre de décision ci‑dessous qui est accompagné de directives pour chaque étape du processus.

Diagramme grandeur réelle

Étapes de l’arbre de décision et directives connexes

A) L’information générée par une application informatique est‑elle utilisée dans l’exécution d’un contrôle auquel nous avons l’intention de nous fier ou pour nos tests de corroboration?

Dans le cadre de nos procédures d’audit, l’auditeur peut identifier l’information générée par une application informatique à n’importe quelle étape de l’audit, cependant, en général, cela se produit au moment de la compréhension et de l’évaluation l’efficacité de la conception des contrôles qui répondent aux risques d’anomalies significatives au niveau des assertions et font partie de la composante « activités de contrôle » (BVG Audit 5035.1) ou lors de la planification et de l’exécution des procédures de corroboration.

Après avoir déterminé qu’un rapport est important et utilisé dans l’exécution efficace d’un contrôle ou dans ses procédures de corroboration, l’auditeur évalue, en se basant sur les aspects à considérer décrits dans l’arbre, si l’information générée par une application contenue dans le rapport est fiable aux fins de l’utilisation prévue.

B) L’information générée par une application informatique est‑elle appropriée aux fins de son utilisation prévue?

Avant d’élaborer sa stratégie d’audit, l’auditeur doit acquérir une compréhension des fins de l’utilisation prévue de l’information générée par une application informatique. L’acquisition de la compréhension de ces fins d’utilisation aide l’auditeur à déterminer l’information du rapport qui est pertinente à l’audit. L’approche de test peut varier selon le type d’information et les fins de l’utilisation prévue. Par exemple, il n’est pas toujours nécessaire de vérifier l’exactitude arithmétique (p. ex. si le rapport ne présente pas les montants calculés, les totaux partiels et les totaux.

C) L’information générée par une application informatique est‑elle fournie par un fournisseur de services indépendant?

L’information utilisée par la direction ou par l’équipe de mission pourrait être conçue et produite par un fournisseur de services indépendant. La direction devra mettre en place des contrôles servant à surveiller ce genre d’activités dans le cadre du système de contrôle interne de l’entité. L’externalisation ne libère pas la direction de ses responsabilités de surveillance (p. ex. contrôles complémentaires de l’entité utilisatrice). Lorsque les analyses ou les conclusions de la direction sont fondées sur l’information provenant d’un fournisseur de services indépendant, la fiabilité de cette information devra aussi être évaluée par la direction dans le cadre de son système de contrôle interne.

Lorsque l’auditeur planifie de se fier à un rapport présenté selon la norme NCMC 3416 (ou son équivalent) pour l’information générée chez l’organisation de services, y compris l’évaluation de la fiabilité de l’information utilisée par la direction pour exécuter les contrôles pertinents ou utilisée par l’auditeur dans le but d’exécuter les procédures de corroboration, il détermine si l’information fait partie de l’étendue du rapport de l’auditeur de la société de services. Si, dans le rapport, l’information n’est pas explicitement identifiée dans la description de l’application, ou dans la description des tests effectués par l’auditeur, des procédures additionnelles seront probablement nécessaires si l’auditeur prévoit se fier aux contrôles qui utilisent l’information et/ou les rapports générés par l’organisation de services. Ces procédures additionnelles peuvent comprendre l’obtention d’éléments probants la fiabilité de l’information de la direction, de l’organisation de services et de son auditeur ainsi que la compréhension de comment et quels rapports font l’objet de tests dans le cadre de la mission de cet auditeur. Si l’auditeur détermine que l’information pertinente n’est pas comprise dans le rapport ou dans l’étendue des tests de la mission de l’auditeur de services, il doit déterminer dans quelle mesure des éléments probants supplémentaires sont nécessaires pour évaluer la fiabilité de l’information.

La détermination de la nature et de l’étendue des éléments probants supplémentaires requis est une question de jugement professionnel. Également, il est important de tenir compte des directives de la section BVG Audit 6040.

D) L’information générée par une application informatique (A) doit être utilisée pour un test de détail de corroboration et (B) ne comprend pas les attributs sur lesquels s’appuie la sélection des éléments à tester (sauf si les valeurs monétaires sont utilisées pour une sélection fondée sur la couverture).

Lorsque l’auditeur utilise l’information générée par une application informatique comme population des tests de détail de corroboration, les objectifs de test de l’exhaustivité et de l’exactitude de l’information peuvent varier selon les fins d’utilisation prévues.

Par exemple, si l’auditeur utilise l’information d’un rapport (p. ex. analyse de compte ou liste d’opérations) pour sélectionner de manière non statistique un échantillon d’éléments à tester ou pour sélectionner des éléments d’un test ciblé basé sur les valeurs élevées, il peut généralement tester l’exhaustivité de la population des manières suivantes :

• Tester l’exactitude arithmétique du rapport;
• Retracer le total du rapport au grand livre général.

Dans de telles situations, les tests de corroboration de l’information sur les comptes ou sur les opérations contenue dans le rapport peut souvent être utilisée/exploitée comme éléments probants l’exactitude de l’information sous-jacente comprise dans le rapport. L’auditeur évalue alors si les procédures de corroboration agrégées (c.‑à‑d. les procédures sur l’exhaustivité décrites ci‑dessus et les procédures de corroboration à exécuter sur l’exactitude) fournissent suffisamment d’éléments probants appropriés au sujet de l’exactitude et de l’exhaustivité de l’information.

Cependant, dans un test ciblé, la sélection des éléments ciblés à tester pourrait être basée sur un attribut en particulier. Par exemple, le test ciblé des ventes à destination FAB dans le test de séparation des périodes à la fin de l’exercice pour déterminer si les livraisons ont été faites avant la fin de l’exercice. Dans ce cas, en plus des procédures mentionnées dans l’exemple ci‑dessus, l’auditeur doit tester l’exactitude des attributs particuliers qu’il utilise pour cibler les éléments à tester (c.‑à‑d. conditions de destination FAB).

L’évaluation du caractère adéquat de la provision pour créances douteuses en se basant sur un rapport chronologique des créances en est un autre exemple. La plupart du temps, l’auditeur serait capable de tester l’exhaustivité en réconciliant le total des créances selon le rapport au grand livre général, mais il faudrait concevoir un test séparé pour l’exactitude de la chronologie présentée dans le rapport généré par le système. Probablement, l’auditeur rapprocherait une sélection de factures du rapport aux documents justificatifs, recalculerait la chronologie qui serait comparée à celle reflétée dans le rapport. Pour des directives sur le test des attributs du rapport sur lesquels s’appuie l’auditeur pour sélectionner les éléments à tester, voir les directives à la section E) ci-dessous.

Dans certains cas, il est possible que l’information pertinente contenue dans le rapport ait déjà été évaluée dans le cadre d’autres procédures exécutées. Par exemple, dans le scénario ci‑dessus, l’auditeur pourrait se fier aux contrôles du processus de saisie des commandes s’ils contiennent des contrôles de l’exactitude de l’attribut de l’opération FAB – destination comparé à FAB – point d’expédition. Dans de telles circonstances, l’auditeur pourrait déterminer que l’exécution du test de corroboration des conditions FAB n’est pas nécessaire.

Lorsque le rapport généré par le système utilisé dans l’audit comprend des attributs non pertinents pour le test effectué (p. ex. numéro de client inclus dans le rapport chronologique des créances), il n’est pas nécessaire de tester l’exhaustivité et l’exactitude de ces attributs.

Consulter l’illustration dans la section Information générée par une application informatique – Approche de test – Exhaustivité et exactitude des données de base présentées dans le rapport (logique de rapport), qui résume les types de procédures de test qui peuvent s’appuyer sur des rapports générés par le système et les situations typiques où l’auditeur effectue un test la fiabilité selon l’approche décrite ci‑dessus.

E) L’auditeur s’attend‑il à ce que ses tests des CGI et des contrôles du traitement de l’information liés à l’application qui génère l’information soient efficients et efficaces?

Les prochaines étapes de l’évaluation des procédures nécessaires pour traiter la fiabilité de l’information générée par une application informatique varieront selon que l’entité a conçu et mis en œuvre ou non des CGI et des contrôles du traitement de l’information pertinents aux données de base ainsi qu’à l’application qui a généré l’information et aussi selon que ces contrôles fonctionnent efficacement ou non.

De plus, l’auditeur doit se demander si l’information utilisée provient directement de l’application ou si elle a été modifiée (p. ex. données téléchargées et filtrées dans une feuille de calcul) et, donc, tenir aussi compte des directives de BVG Audit 2051.

Absence d’appui sur les CGI et les contrôles du traitement de l’information – Mise en œuvre des procédures de tests de corroboration de l’information générée par une application informatique

Si l’auditeur ne prévoit pas tester les CGI et les contrôles d’application ou qu’il les teste et, ensuite, constate qu’ils ne fonctionnent pas efficacement, il doit effectuer un test de corroboration des attributs pertinents dans chaque occurrence de l’information qu’il prévoit utiliser aux fins de l’audit. Par exemple, si l’auditeur teste un contrôle mensuel deux fois au cours d’un exercice, il doit alors effectuer un test de corroboration des attributs pertinents dans l’information sous-jacente au moins pour les deux tests effectués.

Les points à étudier pour établir la nature des tests de corroboration et accroître l’étendue des tests sur l’information sous-jacente comprennent notamment :

• la source et la fiabilité attendue de l’information sous-jacente (p. ex. provient-elle d’applications indépendantes du processus d’information financière? Est‑elle explicite ou complexe?);
• l’importance et le niveau d’assurance attendu du contrôle manuel dépendant des TI ou des tests de corroboration.

Pour un test de corroboration, il faut évaluer s’il serait efficace et efficient de concevoir le plan d’audit pour minimiser le nombre de rapports produits à utiliser (p. ex. obtenir un rapport couvrant toute la période plutôt que plusieurs rapports couvrant de courtes périodes) aux fins de notre test. Une telle approche n’est pas appropriée lorsque l’information générée par une application est utilisée pour le fonctionnement d’un contrôle, car l’information générée par une application utilisée dans l’exécution d’un contrôle doit être testée pour chaque occurrence du test du contrôle.

Effectuer un test de corroboration des attributs du rapport

La nature des procédures de corroboration à exécuter dépendra des attributs de l’information qui sont pertinents à leurs fins d’utilisation du rapport dans l’audit. Dans une telle situation, l’approche la plus commune est l’application des concepts tirés de la section BVG Audit 7043 pour effectuer un test d’inclusion intégrale sans erreur, comme suit :

• Pour évaluer si l’information est présentée de manière exacte dans le rapport, sélectionner un échantillon d’éléments du rapport et les retracer dans l’application en question selon des attributs particuliers (p. ex. le nom du client ou le numéro de la facture);
• Pour évaluer si l’information dans l’application est présentée de manière exhaustive dans le rapport, sélectionner un échantillon (différent de celui choisi pour tester l’exactitude) d’éléments de l’application et les retracer au rapport selon des attributs particuliers (tels que le nom du client ou le numéro de la facture).

Supposons que, par exemple, la direction génère, mensuellement, un rapport de toutes les notes de crédit (avoirs) supérieures à un million de dollars pour en examiner la preuve d’autorisation. L’auditeur a évalué la conception de ce contrôle et déterminé que le reste de la population des notes de crédit inférieures au seuil de 1 million de dollars n’est pas significatif ni individuellement ni au total; par conséquent le seuil est jugé approprié. L’auditeur effectue ensuite son propre test sur le rapport pour vérifier la fiabilité du rapport utilisé par la direction dans l’exécution du contrôle. L’auditeur pourrait décider d’effectuer un test d’inclusion intégrale et sans erreur d’acceptation-rejet comme suit :

• Pour évaluer si l’information est présentée de manière exacte dans le rapport, l’auditeur sélectionne un échantillon de notes de crédit du rapport et les retrace dans l’application source selon des attributs particuliers (p. ex. le numéro du compte client ou les valeurs monétaires);
• Pour évaluer si l’information dans l’application est présentée de manière exhaustive dans le rapport, l’auditeur obtient la liste de toutes les notes de crédit extraite de l’application qui traite les notes de crédit, il la filtre pour retenir seulement les notes de plus de 1 million de dollars, et réconcilie cet échantillon avec le rapport que la direction utilise dans son contrôle mensuel. L’auditeur doit aussi effectuer un test d’exhaustivité de la liste des notes de crédit utilisée dans ce test (p. ex. rapprocher le total au grand livre général, vérifier la séquence numérique).

Déterminer la nature, la chronologie et l’étendue des éléments probants nécessaires pour évaluer la fiabilité de l’information générée par une application dépend, en grande partie, des faits et circonstances de chaque mission, ainsi que du type de rapport à évaluer (type, personnalisé, requête). Les exemples ci‑dessous décrivent comment l’auditeur peut tester les rapports le plus couramment utilisés. D’autres rapports peuvent aussi être utilisés par l’entité et par l’auditeur; des tests semblables seraient effectués pour ces rapports. À noter que cette liste de procédures n’est pas complète et que l’auditeur doit déterminer si des procédures additionnelles sont requises pour déterminer la fiabilité des rapports de l’entité.

Rapport chronologique des créances :

• Effectuer un test acceptation-rejet sur la date et le montant de chaque opération aux documents justificatifs, tels que les factures de vente et, s’il y a lieu, les documents de livraison, pour vérifier les montants dans le rapport des créances et pour vérifier l’exactitude du classement des factures par tranche d’âges;
• Retracer le solde total du rapport au montant inscrit dans le grand livre général pour vérifier l’exhaustivité du rapport. S’il y a des écarts entre le rapport et le grand livre général, tester le rapprochement entre le rapport et le livre des comptes.

Ces procédures permettent à l’auditeur de déterminer si le rapport chronologique est fiable et s’il peut servir dans les procédures détaillées liées à la provision pour créances douteuses. Si d’autres rapports sont utilisés par l’auditeur pour auditer le calcul de la provision pour créances douteuses, il faudrait évaluer les tests de l’information appropriés.

F) L’auditeur a-t‑il déjà évalué l’information générée par une application informatique présentée dans le rapport?

Si des CGI identifiés sont efficaces pendant la période écoulée depuis la dernière fois où l’auditeur a testé la fiabilité du rapport pour la période durant laquelle il prévoit utiliser l’information générée par une application, si l’auditeur a évalué la validité du rapport dans un audit antérieur et s’il peut vérifier que le rapport n’a pas changé depuis la dernière fois où il l’a testé, il pourrait conclure qu’il dispose d’éléments probants suffisants sur la fiabilité de l’information fournie par le rapport et qu’il n’a pas besoin de répéter les procédures de test spécifiques effectuées dans une période antérieure (voir les considérations particulières à la section G) ci‑dessous). Cette approche est appelée stratégie d’étalonnage. Normalement, si plus de trois ans se sont écoulés depuis le dernier test du rapport (c.‑à‑d. test de référence), l’auditeur n’utiliserait pas cette stratégie dans l’audit en cours à moins que les circonstances décrites à la section G1) ne s’appliquent.

G) L’auditeur a-t‑il l’intention d’appliquer une stratégie d’étalonnage?

La stratégie d’étalonnage pourrait être un moyen efficient d’évaluer la fiabilité de l’information générée par une application. Toutefois, cette stratégie n’est pas nécessairement efficiente ou efficace pour tous les rapports. Par exemple, si l’auditeur ne peut pas déterminer la date de modification du rapport la plus récente sans devoir faire des analyses et des travaux poussés, il pourrait être plus efficient de tester le rapport autrement. Si l’auditeur ne prévoit pas utiliser cette stratégie, il doit passer à la section I) ci‑dessous.

Il n’est pas nécessaire que l’auditeur effectue un test direct du rapport pour l’exercice considéré lorsqu’il suit une stratégie d’étalonnage et s’il est en mesure de déterminer que les éléments suivants s’appliquent :

• l’auditeur n’a pas à rétablir la base de référence (voir section G1 pour directives);
• les procédures exécutées dans la période de référence initiale restent suffisantes pour les besoins de l’exercice courant (voir section G2 pour directives);
• les CGI soutiennent le fonctionnement cohérent et efficace de l’information générée par une application depuis que la base de référence a été établie et tout au long de la période pour laquelle l’auditeur prévoit utiliser l’information (voir section G3) pour directives);
• le rapport n’a pas changé depuis qu’il a été testé (voir section G4 pour directives)

L’auditeur documente son évaluation des facteurs ci‑haut énumérés lorsqu’une stratégie d’étalonnage est prévue.

Les mêmes éléments à considérer pour l’étalonnage mentionnés dans les sections F et G pourraient aussi s’appliquer à d’autres types de dépendances aux TI.

G1) L’auditeur a-t‑il besoin de rétablir la base de référence?

L’étalonnage consiste à tester le rapport dans une période de référence initiale pour obtenir des éléments probants au sujet de la fiabilité de ce rapport puis à effectuer d’autres procédures par la suite (c.‑à‑d. tester les CGI pertinents et les contrôles du traitement de l’information, s’il y a lieu) dans les exercices suivants pour obtenir la preuve que l’information générée par une application reste fiable. Déterminer le moment auquel il faut rétablir la base de référence est une question de jugement professionnel. La section G2 résume certains des facteurs courants à considérer à cet égard.

Normalement, l’auditeur établit la base de référence des rapports qu’il a l’intention d’utiliser au moins une fois tous les trois ans. Cependant, la période pourrait être prolongée lorsqu’il est évident qu’aucun changement susceptible d’affecter le maintien de sa fiabilité n’a été apporté au rapport, au sein de l’entité et dans son environnement. Vu les changements communs ayant une incidence sur la plupart des entités au fil du temps, il faut faire preuve de prudence au moment d’envisager le prolongement de la période.

G2) Les procédures mises en œuvre dans la période de référence initiale restent-elles suffisantes au regard des besoins de l’exercice considéré?

Étant donné que l’environnement de la direction, les contrôles et les rapports changent au fil du temps, l’auditeur pourrait déterminer que les procédures effectuées dans un exercice antérieur pour établir une base de référence ne sont plus suffisantes. Plusieurs facteurs pourraient indiquer la présence de tels changements, tels des changements dans l’information contenue dans le rapport sur lequel s’appuie l’auditeur, des changements aux contrôles ou dans la technologie, des indications d’erreurs associées au rapport ou, encore, les résultats obtenus d’autres procédures. Par conséquent, l’auditeur pourrait envisager de tester à nouveau le rapport (c.‑à‑d. établir une nouvelle base de référence). Par exemple, dans les exercices antérieurs, un rapport de gestion qui montrait la rentabilité par code d’entité a été évalué selon chaque code d’entité compris dans l’étendue. Cependant, vu la croissance qu’ont connue plusieurs nouveaux marchés, des codes d’entité additionnels sont maintenant compris dans l’étendue de l’audit et doivent être considérés comme de l’information pertinente pour nos procédures d’audit. Donc, les procédures d’audit effectuées dans un exercice antérieur pourraient cesser d’être suffisantes en raison d’un changement dans les objectifs sous-jacents (c.‑à‑d. codes d’entités additionnels dans l’étendue).

L’auditeur tient aussi compte des procédures exécutées la dernière fois que le rapport a été testé (c.‑à‑d. lorsque la base de référence a été établie) pour évaluer si les procédures répondent aux objectifs de l’exercice considéré et si tous les scénarios applicables ont été testés pour montrer que le rapport fonctionne comme prévu. Pour renforcer la prise en compte de l’évaluation de l’exercice antérieur, l’auditeur inclut normalement les résultats du test de cet exercice dans les feuilles de travail de la période considérée, en plus de la documentation de son évaluation de la suffisance des procédures de l’exercice considéré.

G3) Les CGI soutiennent‑ils le fonctionnement uniforme et efficace de l’information générée par une application depuis que la base de référence a été établie?

Après qu’un rapport ait été testé et jugé exact et complet (c.‑à‑d. après avoir établi une base de référence), des CGI efficaces soutiennent le fonctionnement uniforme et efficace de l’information générée par une application. Par exemple :

• Les contrôles des changements au programme pourraient fournir les éléments probants des changements à l’information ou aux rapports sont demandés, autorisés, exécutés, testés et mis en œuvre et si l’accès aux programmes et aux données est limité comme il se doit ou non;
• Les contrôles de limitation de l’accès pourraient fournir la surveillance des utilisateurs ayant la capacité de modifier ou d’approuver les modifications des rapports et les données.
• Les contrôles des opérations informatiques peuvent fournir la preuve du transfert de données dans les rapports ou des rapports générés automatiquement au moyen d’un processus planifié ou une activité événementielle telle qu’un rapport d’expédition de nuit ou un rapport d’écarts relatif à un rapprochement croisé.

Si l’information ne vient pas d’une application pour laquelle des éléments probants des CGI n’ont pas été obtenus, il faut envisager d’ajouter cette application dans l’étendue des tests des CGI, ou effectuer d’autres procédures de validation de corroboration pour évaluer l’exhaustivité et l’exactitude de l’information à chacune de ses utilisations (p. ex. effectuer un test de corroboration de l’information en cause pour toutes les informations utilisées aux fins de l’audit).

La nature et l’étendue des autres procédures de validation pourraient comprendre les considérations suivantes :

• Il est possible que le risque de changements non autorisés aux programmes et aux données soit suffisamment faible pour que l’auditeur puisse limiter les éléments probants dont il a besoin concernant l’efficacité d’une partie ou de l’ensemble des CGI lorsqu’il évalue le fonctionnement uniforme et efficace du programme ou de la routine qui génère l’information utilisée dans un contrôle. Par exemple, lorsque l’information provient d’un rapport type du système ou d’une application type du fournisseur sans personnalisation, ou lorsqu’il n’y a pas de code source modifiable par l’entité, il est possible que le risque de changement dans le rapport soit faible. Par conséquent, une évaluation de l’efficacité des contrôles des changements au programme pourrait être moins importante pour notre évaluation. Par contre, dans certains scénarios, tels que celui des applications standards fournies par un petit fournisseur dont l’application est largement utilisée, les procédures pourraient être semblables aux procédures que l’auditeur exécute pour une application maison personnalisée.
• D’autres types d’éléments probants, considérés individuellement ou en conjonction avec des tests des CGI, pourraient fournir suffisamment d’éléments probants au sujet du fonctionnement uniforme et efficace du programme ou de la routine qui génère l’information. Par exemple, des éléments probants fiables pourraient démontrer que le programme n’a pas changé depuis la dernière fois où il a été testé (p. ex. la date de la dernière modification établie par l’application). Un spécialiste en audit informatique peut soutenir la procédure lors de l’évaluation de cette approche.

G4) Le rapport a-t‑il changé depuis la dernière fois où il a été testé?

Pouvoir compter sur des CGI efficaces ne suffit pas pour justifier la stratégie d’étalonnage. L’auditeur doit documenter les éléments probants obtenus pour vérifier que le rapport n’a pas changé depuis qu’il a été testé la dernière fois. La nature et l’étendue des éléments probants obtenus pour ce faire peuvent varier pour différentes raisons, notamment l’évaluation par l’auditeur de la solidité des contrôles de l’entité par rapport aux changements au programme, la fréquence des changements au rapport ainsi que le type de rapport (type, personnalisé, requête). L’auditeur doit évaluer s’il a obtenu des éléments probants concernant les changements au rapport lors du test des CGI.

Pour certaines applications, il est possible d’inspecter la date du dernier changement associé au rapport. Dans de telles circonstances, l’auditeur peut identifier les changements apportés au rapport depuis la dernière fois où il a été testé. Dépendamment de leur nature, les changements peuvent avoir une incidence sur l’approche de test planifié.

Une rustine ou une mise à niveau d’une application commerciale pourrait modifier un rapport type. S’il y a lieu, l’auditeur documente sa compréhension des changements compris dans une rustine ou une mise à niveau et son incidence (l’absence d’incidence) sur les rapports types.

Pour certaines applications et certains rapports, il n’est pas possible d’inspecter la date du dernier changement portant sur l’application, le programme ou le rapport. Dans ces situations, l’auditeur pourrait :

• Obtenir et comparer le code source de la version courante du rapport avec le code source du rapport au moment du test fait dans la période de référence. Un spécialiste en audit informatique participerait normalement dans l’évaluation potentielle des changements au code source du rapport.
• Se renseigner auprès du responsable des contrôles et/ou du responsable des TI et corroborer ensuite l’information obtenue quant à savoir si des changements ont été apportés au rapport. Par exemple, le responsable des contrôles pourrait indiquer qu’un rapport n’a pas changé depuis le dernier test. Pour corroborer cette explication, l’équipe de mission pourrait examiner la description des changements au moyen de mots clés, tels que le nom du rapport, et identifier les billets de changement associés au rapport. Si l’examen d’un billet de changement révèle que seul l’en-tête du rapport a été modifié, il peut être approprié d’accepter l’affirmation du responsable des contrôles selon laquelle aucun changement important n’a été apporté au rapport.

L’auditeur doit aussi vérifier (soit directement, soit lors de ses tests des CGI) que les rapports sur lesquels il s’appuie ne permettent pas d’interventions manuelles susceptibles de les altérer. De plus, l’auditeur doit documenter les éléments probants obtenus en observant la création du rapport, notamment la définition et l’établissement des paramètres utilisés pour créer le rapport (p. ex. la période couverte par le rapport).

Il faut se rappeler que la demande de renseignements à elle seule ne suffit pas pour déterminer qu’un rapport n’a pas changé depuis la dernière fois où il a été testé.

De plus, même avec l’approche d’étalonnage, l’auditeur devrait vérifier que le total du rapport correspond au total selon le grand livre général (ou grand livre auxiliaire en cause), s’il y a lieu.

H) Tester l’exactitude arithmétique de l’information générée par une application informatique

Il faut tenir compte de plusieurs facteurs au moment de tester l’exactitude arithmétique des rapports. Ces facteurs sont dictés par le type de rapport (type, personnalisé, requête) ainsi que par la complexité des calculs en jeu. Pour vérifier l’exactitude arithmétique des rapports, l’auditeur envisage généralement les procédures suivantes :

Test de corroboration de l’exactitude arithmétique

Dans les missions où l’auditeur n’a pas de base lui permettant de s’appuyer sur les rapports types pour ce qui est de l’exactitude arithmétique (p. ex.une application complexe pour laquelle l’auditeur ne planifie pas de tester les CGI), il doit obtenir des éléments probants suffisants et appropriés de l’exactitude arithmétique des rapports en reprenant le calcul.

Demander la version électronique du rapport et utiliser un logiciel, Excel, Access ou autre, pour refaire le calcul des sous-totaux et/ou du total du rapport pourrait être un moyen efficace de tester l’exactitude arithmétique de grands rapports tels que la liste chronologique détaillée des créances.

Lorsque l’auditeur demande la version électronique d’un rapport, il est important qu’il connaisse le nombre approximatif d’enregistrements (opérations, factures) que le rapport contient. Grâce à cette information, l’auditeur peut demander le bon format de données à l’entité (Excel, Access ou autre). Excel est le moyen le plus facile de tester l’exactitude arithmétique. Cependant, un fichier Excel peut contenir un maximum de 1 048 576 lignes. Si le nombre de lignes du rapport dépasse cette limite, un spécialiste en audit informatique peut intervenir en obtenant les données de l’entité et en testant l’exactitude arithmétique des rapports à l’aide d’Access ou d’autres outils.

Lorsqu’il n’est pas possible de tester l’exactitude arithmétique du rapport par voie électronique, l’auditeur pourrait sélectionner des sous-totaux de page ou des sous-totaux de soldes de créances et exécuter un test acceptation-rejet (voir exemples de procédures ci‑dessous), en suivant les directives énoncées à BVG Audit 7043. Comme l’objectif du test est de vérifier que le rapport est exact, aucun écart ne serait acceptable. S’il n’y a aucune erreur, l’auditeur peut accepter les résultats du test et conclure que le total du rapport est exact. Au contraire, si une erreur arithmétique est trouvée, normalement, l’auditeur rejetterait l’exactitude du rapport et demanderait à l’entité de recalculer le total du rapport, puis il referait le test.

Dans de rares situations où il n’est pas possible d’élaborer une approche efficace et efficiente pour tester l’exactitude arithmétique (p. ex. à cause de la taille et de la structure du rapport), il y aurait lieu de discuter d’autres stratégies de test avec le spécialiste en audit informatique.

Autres techniques possibles pour tester l’exactitude arithmétique :

• Lorsque l’auditeur choisit de tester des procédures programmées pour l’exactitude arithmétique d’un rapport, il doit obtenir des éléments probants montrant qu’elles fonctionnent comme prévu, comme lorsqu’il teste n’importe quel autre contrôle automatisé (p. ex. en combinant des procédures de test telles qu’une demande de renseignements, la réexécution ou l’examen des manuels du fournisseur de logiciel, ou en évaluant la logique de programme sous-jacente). Pour plus de directives sur les techniques de test des procédures programmées, consulter les directives sur le test des contrôle automatisés dans BVG Audit 6054, y compris sur le recours à une stratégie d’étalonnage.
• Dans le cas des progiciels standards largement distribués, des rapports types peuvent être considérés exacts si l’auditeur obtient suffisamment d’éléments probants appropriés attestant de l’incapacité de l’entité d’accéder ou de modifier les codes sources fournisseurs applicables (p. ex. au moyen d’une combinaison de demandes de renseignements précises adressées à des employés des services informatiques de l’entité et des éléments probants fondés sur l’application, comme la date de modification marquée avec un timbre dateur, et/ou en discutant avec un spécialiste en audit informatique, qui possède les connaissances et le savoir-faire concernant le progiciel). La justification touchant la dépendance à l’égard d’un progiciel standard et les éléments probants obtenus doivent être consignés au dossier d’audit.

I) Exécuter des procédures pour tester la fiabilité de l’information générée par une application informatique lorsqu’il est établi que les CGI et les contrôles d’application fonctionnent efficacement

Lorsque l’auditeur s’attend à ce que ses tests des CGI et des contrôles du traitement de l’information liés à l’application générant l’information soient efficaces et efficients, normalement il serait suffisant d’évaluer la fiabilité de l’information générée par une application informatique seulement une fois pendant la période, même si plusieurs occurrences de la même information générée par une application sont utilisées tout au long de l’audit (pour les tests des contrôles et pour les tests de corroboration). Tester l’information se ferait alors à l’aide d’une combinaison de test de l’exactitude arithmétique, de rapprochement du total au grand livre général (s’il y a lieu) et une des techniques décrites ci‑dessous. Envisager la nécessité de faire intervenir un spécialiste en audit informatique pour déterminer et exécuter l’approche de test la plus efficace et efficiente. À noter que, également, si l’entité saisit les paramètres chaque fois que le rapport est exécuté, ces paramètres (p. ex. les fourchettes de dates) doivent être évalués chaque fois que le rapport est utilisé.

Test de détails des attributs pertinents

L’une des méthodes utilisées pour confirmer la fiabilité de l’information générée par une application informatique est d’effectuer un test acceptation-rejet. L’approche détaillée pour ce type de test est décrite dans la section (E) ci-dessus.

Effectuer un examen de code indépendant

Lorsqu’il effectue un examen de code indépendant, l’auditeur évalue la logique technique du rapport pour déterminer si ce dernier est généré comme prévu (p. ex. combinaison ou exclusions de codes d’entité ou de types d’opérations). L’auditeur met aussi en œuvre des procédures pour obtenir des éléments montrant que le code examiné est le même que celui utilisé dans l’application en cause.

Pour effectuer un examen de code, l’auditeur doit posséder les capacités et les connaissances techniques suffisantes pour pouvoir formuler un point de vue indépendant sur le caractère suffisant du code par rapport au but prévu, et ce tant pour les simples langages de requête, comme SQL, que pour les langages de programmation d’ordinateur central plus complexes, comme COBOL. Même écrit dans un langage de requête simple, le code lui‑même peut être complexe, ce qui joue sur le niveau de connaissances que doit posséder celui ou celle qui examine le code. L’auditeur documente son évaluation de ses compétences dans ce domaine, y compris lorsqu’un spécialiste en audit informatique participe à l’examen.

En examinant le code, l’équipe de mission devrait évaluer quels éléments du code sont pertinents à l’utilisation de l’information qui servira l’audit et se faire une opinion sur le caractère approprié du code.

En général, il y aurait lieu d’annoter la ligne du code (c.‑à‑d. ajouter des commentaires) pour démontrer notre compréhension et se concentrer sur les secteurs complexes ou les critères utilisés dans le rapport.

Par exemple, dans le test de corroboration de la paye, l’auditeur utilise le rapport de la direction donnant les noms des employés par emplacement, y compris leur emploi, leur niveau et leur échelon salarial, pour procéder à l’analytique des données désagrégées de la paye. L’équipe de mission examine le code pour inspecter le SQL sous-jacent utilisé pour générer le rapport. Un spécialiste en audit informatique expert en SQL inspecte les instructions SQL pour déterminer s’il fait référence aux bonnes données de base (p. ex. ressources humaines et application de la paye) et si le code inclut des instructions pour générer l’information pertinente (telle que l’emplacement, l’emploi, l’échelon salarial). Un spécialiste en audit informatique examine aussi les situations où le langage exclut des données d’information ou des paramètres sélectionnés, ou encore, saisit seulement un groupe choisi de paramètres ou de données d’information. Pour démontrer son examen du code, l’équipe doit laisser des commentaires (ou annoter le code) sur le code SQL indiquant quelles instructions du code sont en corrélation avec les données, les champs ou les calculs générés par le rapport. Cette documentation, comprise dans les feuilles de travail, renforce les résultats de l’évaluation du code et de la détermination quant à l’exhaustivité et l’exactitude du rapport.

Réexécuter le rapport/la requête à l’aide d’un extrait de données

L’auditeur doit évaluer s’il a la capacité d’obtenir un extrait des données utilisées dans le rapport. D’après sa compréhension du rapport, l’auditeur peut répliquer le produit en exécutant des requêtes indépendantes sur les données extraites ou à l’aide d’une fonction d’Excel, telle l’insertion d’un tableau croisé dynamique ou le tri, pour, ensuite, en comparer les résultats au produit obtenu du rapport.

En reprenant l’exemple du rapport sur les notes de crédit présenté à la section E), l’auditeur pourrait avoir décidé d’évaluer l’exhaustivité et l’exactitude du rapport en le réexécutant. Il obtient la liste complète de toutes les entrées de notes de crédit d’une application qui traite ces notes de crédit une fois par mois. L’auditeur filtre ensuite celles qui dépassent 1 million de dollars et vérifie la concordance en comparant le nombre total des notes de crédit, leurs montants et les autres données d’information pertinentes au rapport qu’utilise la direction. L’auditeur est en mesure de recréer le rapport mensuel utilisé par la direction et d’évaluer la fiabilité de l’information qu’elle utilise dans l’exécution du contrôle.

Cette option peut être plus profitable pour les rapports moins complexes. Plus ils se complexifient, plus les rapports exigent du travail pour arriver à les recréer.

Effectuer un test indépendant à l’aide d’une fonction de test intégrée

À la lumière des concepts énoncés à BVG Audit 6054, l’auditeur pourrait envisager d’établir une fonction de test intégrée dans l’application de l’entité. Effectuer un tel test signifie exécuter des exemples d’opération au moyen du programme ou de la routine de l’application pour ensuite comparer le produit obtenu aux résultats attendus.

Utiliser ce genre de fonction peut se révéler efficace lorsque plusieurs rapports sont générés à partir d’une même application et que les données peuvent être utilisées pour générer et tester plusieurs rapports. Par exemple, au chapitre de l’activité de placement, les opérations de placement elles-mêmes peuvent être utilisées pour vérifier les rapports de résultats, les rapports des avoirs, les rapports d’achat et de vente et les autres tableaux connexes.

Après avoir conçu une série d’opérations de test qui répondent à certains critères, l’équipe les traite et inspecte ensuite les rapports pour vérifier si les opérations qu’elle a créées sont incluses ou exclues comme il se doit. Pour poursuivre avec l’exemple de rapport des notes de crédit expliqué ci‑haut, l’équipe traiterait deux notes de crédit, l’une supérieure à 1 million de dollars qui devrait être incluse dans le rapport, et l’autre inférieure à 1 million de dollars qui devrait être exclue du rapport.

Dans certains cas, l’entité pourrait demander que ce test soit effectué dans un environnement de test. En effectuant une évaluation dans l’environnement de test, il faudrait envisager de mettre en œuvre des procédures pour déterminer si la fonction évaluée dans l’environnement de test ou dans l’environnement dupliqué s’exécute de la même manière que dans l’environnement de production.

Pour plus de clarté, lorsqu’elle évalue les déficiences du contrôle liées aux CGI dans le cas d’un appui sur les contrôles dépendant des TI et les rapports du système, l’équipe de mission devrait évaluer les risques liés aux déficiences des CGI avant d’évaluer l’impact sur la stratégie d’audit (c.‑à‑d. tester les contrôles compensatoires et/ou effectuer des tests de corroboration additionnels). En évaluant les risques, il y aurait lieu de se demander :

• comment la déficience des CGI pourrait être exploitée;
• si les personnes au sein de l’entité qui ont l’accès pour pouvoir exploiter le contrôle (déficient) ont une motivation quelconque de le faire;
• s’il y a des occasions d’exploiter le contrôle.

L’évaluation des risques contribuera à établir une base d’évaluation de l’impact sur la stratégie d’audit.

Directives du BVG

Tester la sécurité avec des éléments probants concernant les CGI

S’il a été établi, à l’évaluation des risques, que les droits d’accès sont pertinents et que les CGI ont été testés, des contrôles suffisants existent en général dans le domaine de l’Accès aux programmes et aux données. Voir BVG Audit 5035.2 pour explications.

Autres procédures à mettre en œuvre pour tester la sécurité

Si les CGI du domaine de l’Accès aux programmes et aux données ne sont pas testés et que l’auditeur prévoit s’appuyer sur les contrôles dépendants d’une séparation adéquate des tâches, d’autres procédures pour tester si les droits d’accès sont appropriés peuvent être mises en œuvre. L’auditeur peut, par exemple, obtenir la liste des droits d’accès aux fonctions pertinentes et demander des renseignements et procéder par inspection pour valider si les droits d’accès ne présentent pas un risque non atténué lié à une mauvaise séparation des tâches. Comme dans le cas des autres approches dans les autres domaines dépendants des TI, ces procédures sont envisagées à divers moments de la période de telle manière qu’il soit possible de conclure que l’accès est approprié tout au long de la période visée par l’audit. Le risque lié à une mauvaise séparation des tâches peut aussi être géré à l’aide de contrôles manuels. L’auditeur tient compte des deux types de contrôles, manuels et automatisés, lorsqu’il évalue les risques et détermine sa réponse à ces risques, le cas échéant. Pour l’utilisation d’autres procédures pour tester la sécurité, consultez un spécialiste en audit informatique à la phase de la planification.

Directives du BVG

Tester les interfaces avec des éléments probants concernant les CGI

Les contrôles des interfaces servent à vérifier l’exhaustivité et l’exactitude des données transférées entre les applications ainsi que la validité des données reçues. Ils peuvent être manuels ou automatisés, le transfert pouvant être lancé manuellement, et la valeur ou le nombre d’enregistrements rapproché manuellement ou au moyen de totaux de lots des applications. Voici des exemples de contrôles du traitement de l’information automatisés qui pourraient être utilisés pour déterminer que la transmission des données est effectuée d’un système source et reçue par l’application de destination de manière exhaustive et exacte :

• Contrôles de validation utilisés par les applications de destination qui restreignent la réception de données d’interface de certaines applications sources prédéfinies. La validation pourrait se faire à l’aide de codes de reconnaissance des systèmes (p. ex. adresses IP et pointeurs de bases de données). Ces contrôles pourraient aussi vérifier la validité des données reçues.
• Contrôles de validation intégrés dans l’application de destination qui refusera d’accepter les fichiers qui ne sont pas de la bonne date, p. ex. l’application n’acceptera pas le fichier de la veille une deuxième fois.
• Contrôles de validation intégrés dans la transmission des données servant à garantir l’exhaustivité et l’exactitude de la transmission. Par exemple, l’application de destination peut calculer les totaux de contrôle et le nombre des enregistrements des données reçues de sources valides. Il compare les totaux et le nombre à l’information envoyée de l’application source. L’application source compare les totaux de contrôle à ses propres calculs. Si les totaux sont identiques, l’application source enverra une confirmation à l’application de destination. Autrement, l’application de destination ne traitera pas les données.
• Contrôles de validation au moyen des débuts et des fins de fichiers. Les débuts de fichiers peuvent résumer l’information incluse dans les fichiers venant des applications sources. Cette information pourrait comprendre le nombre d’enregistrements, les champs des montants totaux, les débits totaux, les crédits totaux, les tailles des fichiers, etc. L’application de destination importe le fichier enregistrement par enregistrement en calculant les valeurs des contrôles de validation. Lorsque ces valeurs correspondent aux données du début ou de la fin des fichiers, l’information passera à la prochaine étape du processus de validation.

Lorsque les contrôles du traitement de l’information appliqués aux interfaces détectent des différences, il y aura lieu de s’intéresser aux contrôles qui sont exercés pour la présentation des données une nouvelle fois comme étant corrigées.

Les données reçues des applications sources pourront être soumises à des contrôles de validation. Par exemple, si l’entité a établi des règles administratives pour le format de numérotage, les contrôles de validation pourraient être appliqués pour vérifier la cohérence des données reçues par rapport aux règles établies.

Si l’auditeur a conclu que les CGI pertinents qui répondent aux risques découlant du recours à l’informatique pour les interfaces fonctionnent efficacement, il serait peut-être possible de tester les contrôles des interfaces moins souvent que dans le cas contraire.

Autres procédures à mettre en œuvre pour tester les interfaces

Lorsque les CGI appliqués aux opérations informatiques ne sont pas testés et que les interfaces de données sont pertinentes pour notre approche de tests des contrôles ou de corroboration, d’autres approches peuvent être appliquées pour déterminer si les interfaces de données sont efficaces, c’est-à-dire si les données ont été transmises entièrement et avec exactitude. S’il est bien conçu, un rapprochement entre deux applications effectué par l’entité pourra détecter toute donnée incomplète ou inexacte envoyée par interface. Examiner le niveau de précision du contrôle (p. ex. les seuils utilisés dans le rapprochement) et les données rapprochées dans l’application de cette technique. Si les rapprochements de données ne se font pas de manière cumulative ou pour un compte de bilan, il faudrait envisager de tester les rapprochements effectués tout au long de la période pour valider l’exhaustivité et l’exactitude du flux des données.