6054 Tests des contrôles automatisés

sept.-2022

Directives du BVG

En appliquant une approche fondée sur le risque, l’auditeur élabore une stratégie appropriée pour tester les contrôles automatisés du traitement de l’information, les contrôles généraux informatiques (CGI) et les contrôles manuels, du fait qu’il existe entre eux un certain nombre de liens d’interdépendance. Comme il est souligné à la section BVG Audit 5035.2, la possibilité de se fier au bon fonctionnement constant des contrôles automatisés dépend généralement de l’efficacité du fonctionnement des CGI. Se reporter à la section BVG Audit 5035.2 pour obtenir de l’information complémentaire sur le lien entre les CGI et les contrôles automatisés, et sur la manière dont les CGI apportent des éléments probants aux audits. Il faut prendre en considération plusieurs facteurs avant de déterminer la nature, le calendrier et l’étendue des tests des contrôles automatisés du traitement de l’information et des CGI. Ces facteurs sont :

• La qualité et l’efficacité de l’environnement de contrôle informatique et des contrôles directs au niveau de l’entité (CDNE) à l’égard de l’informatique.

• Les connaissances tirées des audits antérieurs et les changements importants, connus ou anticipés, qui touchent ou peuvent toucher les personnes, les processus, les applications, les technologies, les activités ou les conditions d’affaires et qui peuvent avoir une incidence sur l’audit.

• Les contrôles de haut niveau effectués par la direction de l’informatique dans le cours normal de ses activités pour faire le suivi des contrôles.

• Les risques associés aux contrôles automatisés du traitement de l’information et aux contrôles généraux informatiques (CGI) — Les risques associés aux contrôles automatisés du traitement de l’information comprennent : a) les risques inhérents d’anomalies significatives dans les comptes sous-jacents; et b) le risque que les contrôles automatisés du traitement de l’information soient incapables de prévenir ou de détecter une anomalie significative dans les comptes après l’examen de l’efficacité des autres contrôles, comme les contrôles directs au niveau de l’entité (CDNE). Les CGI, sur lesquels s’appuient les contrôles automatisés du traitement de l’information, sont soumis aux mêmes risques, de même qu’au risque de ne pas pouvoir appuyer l’efficacité continue des contrôles automatisés du traitement de l’information.

• Le recours à une stratégie d’étalonnage pour les contrôles automatisés du traitement de l’information.

• Les autres sources d’éléments probants pouvant permettre d’évaluer le fonctionnement continu des principaux contrôles automatisés du traitement de l’information.

Directives du BVG

Les éléments probants obtenus au sujet de la mise en place d’un contrôle automatisé peuvent fournir un certain niveau d’éléments probants quant à l’efficacité du fonctionnement du contrôle automatisé. La combinaison de ces éléments probants avec ceux concernant l’efficacité du fonctionnement des contrôles généraux informatiques (de la date de mise en place du contrôle jusqu’à la période visée par l’audit) peut fournir des éléments probants substantiels sur l’efficacité du fonctionnement du contrôle automatisé en question pendant la période pertinente.

C’est pourquoi le nombre d’éléments que l’auditeur devra tester pour un contrôle automatisé est généralement minime, en supposant qu’il a testé le contrôle auparavant. Cela tient au fait que lorsque l’auditeur s’appuie sur des contrôles automatisés ou sur des calculs automatisés, il teste normalement les CGI de façon à acquérir la certitude que les contrôles et les calculs automatisés continuent de fonctionner correctement. Si les CGI ne sont pas efficaces, il pourrait être plus efficient de tester les contrôles automatisés à l’aide d’autres techniques comme celles décrites à la rubrique « Approche à l’égard des contrôles automatisés en l’absence d’éléments probants à l’appui des contrôles généraux informatiques ».

Que les CGI soient efficaces ou non, l’auditeur doit concevoir le test avec prudence, en s’assurant qu’il vise toutes les itérations critiques du contrôle. Il y a itération d’un contrôle lorsqu’un contrôle automatisé est programmé pour s’exercer différemment en fonction des données d’entrée. Voir les exemples suivants de contrôles comportant de multiples itérations.

Exemple 1 :

Une entité exécute un encan en ligne au cours duquel elle collecte des commissions basées sur le prix obtenu comme suit :

La commission est automatiquement calculée par l’application; cependant, l’auditeur testera les deux scénarios pour obtenir des éléments probants étayant l’exactitude du calcul de la commission.

Exemple 2 :

Tout écart de prix entre une facture et la commande d’achat qui dépasse les limites de tolérance établies a pour effet de bloquer le traitement du paiement. Les limites de tolérance sont de 10 % ou 100 $. L’auditeur conçoit un test qui permettra de vérifier les deux types de limite de tolérance.

Selon la nature du contrôle et des risques y afférents, les éléments probants concernant le fonctionnement du contrôle automatisé peuvent être obtenus par une demande d’informations, l’observation, une inspection et/ou des procédures de réexécution suffisantes pendant l’évaluation de la conception du processus relatif aux opérations connexes. Il peut être nécessaire de tester plus d’une opération pour observer la façon dont tous les aspects significatifs du processus fonctionnent. Par ailleurs, il peut être plus efficient et plus efficace de tester certains contrôles automatisés du traitement de l’information (notamment les contrôles, calculs ou rapports les plus complexes) « par l’intermédiaire de l’application », par exemple en examinant directement les paramètres d’une configuration dans l’application.

Pour décider d’une méthode de test des contrôles automatisés, l’auditeur doit examiner :

• s’il peut obtenir une assurance indirecte quant à l’efficacité des contrôles récemment mis en place grâce à des tests portant sur les contrôles de modification ou de développement des programmes (p. ex. le processus utilisé par la direction pour évaluer le fonctionnement du contrôle dans le cadre de son processus de mise en place de l’application);

• s’il existe une possibilité d’utiliser des tests à double objectif (p. ex. des tests de corroboration dans des audits d’états financiers pouvant aussi fournir des éléments probants à un moment précis sur des contrôles portant sur l’exhaustivité et l’exactitude d’un rapport clé utilisé dans un contrôle manuel);

• si des compétences particulières sont requises (p. ex. pour examiner directement une installation d’un progiciel de gestion intégrée configurable ou pour évaluer la méthode que le client utilise pour tester un contrôle pendant la phase de mise en place de l’application).

Lors de la conception d’un test pour un contrôle automatisé, il faut prendre en compte les fonctionnalités et caractéristiques de ce dernier afin d’évaluer l’efficacité de son fonctionnement dans tous ses aspects significatifs, compte tenu des objectifs de traitement de l’information pour lesquels le contrôle a été conçu. Le concept du « test unique » ne se limite pas au test d’une seule opération exécutée par les contrôles automatisés. Par exemple, il convient d’examiner ce qui suit :

• les champs de données que l’application est programmée pour traiter;
• la logique des calculs programmés;
• si l’application a un niveau de tolérance en ce qui a trait aux instructions automatisées;
• la façon dont les corrections sont approuvées et traitées;
• la façon dont les écarts sont traités;
• les possibilités de contournements manuels ou systématiques.

Lorsque l’auditeur a recueilli ces renseignements et effectué un travail suffisant pour évaluer la conception des contrôles (y compris l’acquisition d’une compréhension de leurs différentes caractéristiques et des cheminements de leurs opérations), il doit juger si ce travail lui a fourni un niveau suffisant d’assurance pour savoir si le contrôle fonctionne tel qu’il a été conçu. Si ce n’est pas le cas, il peut être nécessaire de mettre en œuvre des procédures complémentaires faisant appel à une ou plusieurs des techniques de test décrites ci‑dessus. Par exemple, il peut être plus efficient ou efficace d’examiner directement les paramètres de configuration du rapprochement en trois points dans l’application.

Tester l’exactitude d’un rapport automatisé utilisé pour générer une estimation comptable importante (p. ex. un rapport de stock excédentaire et périmé appuyant une estimation de provision) constituerait un bon exemple d’un cas où l’auditeur pourrait devoir accomplir plus de travail pour vérifier qu’un contrôle automatisé fonctionne tel qu’il a été conçu. Il pourrait évaluer la façon dont le rapport est pris en compte dans la conception des contrôles, et possiblement en être satisfait, en effectuant des demandes d’informations auprès du personnel comptable et du personnel informatique pour savoir quelle est la nature des données contenues dans le rapport et à la manière dont elles sont compilées dans les processus de comptabilité et d’estimation. Si la conception des contrôles est telle que l’exactitude de l’estimation comptable dépend de l’exactitude du rapport, et que cette dernière dépend à son tour de la qualité de la programmation de l’application, l’auditeur devrait mettre en œuvre des procédures destinées à évaluer si le rapport est exhaustif et exact au regard de l’intention de sa conception.

Contrôles automatisés complexes

Dans le cas de certains contrôles automatisés complexes, il peut être difficilement réalisable en pratique, voire impossible, d’évaluer la conception ou l’efficacité du fonctionnement de ces contrôles uniquement au moyen de procédures « manuelles » seules pour comprendre un processus par l’observation du flux d’une opération. Prenons l’exemple d’une application destinée à traiter des réclamations d’assurance maladie. Un processus automatisé pourrait utiliser les données entrées, des contrôles de validation et des tests de caractéristiques pour orienter les opérations vers d’autres chaînes de traitement alors soumises à différents calculs complexes visant à déterminer le montant réel de la réclamation. L’application pourrait prendre en compte des facteurs tels que :

• La réclamation concerne-t-elle la période de contrat en cours?
• Les services médicaux sont‑ils couverts par le régime de la personne?
• Les services sont‑ils dispensés dans le réseau ou en dehors de celui-ci?
• Le montant de la franchise est‑il atteint?
• Une quote-part est‑elle exigée?
• À quel endroit les services ont‑ils été dispensés?

À la différence d’un simple jeu d’écritures, qu’il est facile de rectifier (comme les prix multipliés par les quantités dans le traitement d’une facture de vente), les variations et la complexité de certains processus (comme dans l’exemple des réclamations d’assurance maladie) peuvent exiger des méthodes plus raffinées pour comprendre et évaluer le flux des opérations, les risques d’anomalie et la conception ou le fonctionnement des contrôles.

Directives du BVG

Pour évaluer les conditions de sécurité et d’accès au niveau des applications (autrement dit, pour déterminer « qui a accès à quoi ») :

Comme il est souligné à la section BVG Audit 5035.2, la possibilité de se fier au bon fonctionnement constant des contrôles automatisés dépend généralement de l’efficacité du fonctionnement des CGI connexes. Bien que des CGI efficaces constituent souvent le fondement principal de l’évaluation du fonctionnement continu des contrôles automatisés, il existe d’autres types d’éléments probants, qui, pris seuls ou conjointement avec des tests limités des CGI, peuvent constituer une stratégie d’audit plus efficace pour un ou plusieurs contrôles du traitement de l’information. Par exemple, l’auditeur pourrait considérer :

• Obtenir des éléments probants indiquant que le contrôle automatisé du traitement de l’information n’a pas été modifié depuis son dernier test. Ces éléments probants peuvent provenir de renseignements sur les modifications de l’application, comme la « date de dernière modification » (si ce type de renseignements est accessible et fiable).

• Exécuter des procédures de techniques d’audit assistées par ordinateur (TAAO) capables de réexécuter de façon efficace et avec une fréquence élevée le fonctionnement du contrôle automatisé du traitement de l’information ou peut-être de comparer le code du programme à intervalles fréquents pendant la période d’audit.

• Évaluer les facteurs de risque inhérent et de risque lié aux contrôles, comme des modifications de programmes/données peu fréquentes/complexes (p. ex. une application standard, sans personnalisation ou maintenance du code source chez le client).

• Tester les contrôles automatisés selon une plus grande fréquence pendant la période visée à l’aide des méthodes de tests 1‑5 mentionnées à la rubrique « Techniques de test des contrôles automatisés en présence d’éléments probants à l’appui des contrôles généraux informatiques ».

N’importe quelle technique de test mentionnée ci‑dessus peut être appliquée pour la période d’audit, mais la méthode la plus pratique et la plus efficiente consiste à obtenir la date de la dernière modification associée au contrôle automatisé pour déterminer qu’il n’a pas changé. (Chaque variation du contrôle devrait quand même être testée au moins une fois pendant la période d’audit.) S’il n’est pas possible d’obtenir cette information dans l’application, l’auditeur peut utiliser une des quatre autres techniques de test.

Comme il a été indiqué plus haut, lorsque l’auditeur teste les contrôles automatisés, l’auditeur doit tenir compte de toutes les itérations de chaque contrôle testé et concevoir le test en conséquence. Cela s’applique aussi à la méthode de test des contrôles automatisés lorsque les contrôles généraux informatiques ne sont pas efficaces. Il faut vérifier si la population d’où les éléments à tester sont tirés comprend chaque itération possible. Voir la rubrique « Nature et étendue des tests des contrôles automatisés des applications en présence d’éléments probants à l’appui des contrôles généraux informatiques (CGI) » pour plus d’informations sur les circonstances où les contrôles généraux informatiques sont efficaces.

Directives du BVG

Exemples de contrôles automatisés et suggestions de tests des contrôles :

(*) L’auditeur prend pour hypothèse qu’il a à sa disposition des spécialistes compétents qui comprennent le langage de la base de données utilisé pour écrire la requête. En outre, les procédures appropriées d’audit des contrôles généraux informatiques liés ont été mises en œuvre pour obtenir des éléments probants quant à l’intégrité et à la fiabilité des données.