Compte-rendu de discussions du Groupe de travail technique – Certification | Application de la NCA 315 (suite)

Les membres du groupe de travail technique sur la certification de l’Ordre des comptables professionnels agréés du Québec (Ordre) ainsi que différents professionnels provenant de différents milieux ont tenu une deuxième rencontre spéciale pour discuter de certaines questions soulevées quant à l’application de la NCA 315, Compréhension de l’entité et de son environnement aux fins de l’identification et de l’évaluation des risques d’anomalies significatives. Afin d’en faire bénéficier l’ensemble des CPA, leurs discussions à l’égard de divers sujets sont résumées ci-dessous. Ce compte-rendu présente des éléments de réflexion. Il ne traite pas de tous les sujets, de tous leurs aspects, ni des faits et circonstances propres à une entreprise. Soyez vigilant et référez-vous aux documents d’origine à jour avant de prendre une décision. 

1) En appliquant le paragraphe 26 de la NCA 315, assumant que les contrôles généraux informatiques fonctionnent, que doit-on faire si les contrôles automatisés applicatifs (c.-à-d. contrôles d’applications informatiques) ne fonctionnent pas? 

Un membre mentionne que ce questionnement peut être réalisé au moment des tests de conception et mise en place sur les contrôles applicatifs, mais également lorsque les tests d’efficacité sont effectués. 

Un autre membre mentionne que la NCA 330.17 traite de ce sujet. « Si des écarts dans l’application des contrôles sur lesquels l’auditeur a l’intention de s’appuyer sont détectés, il doit procéder à des demandes d’informations précises afin de comprendre la situation et ses conséquences potentielles, et il doit déterminer : (Réf. : par. A42)
a)     si les tests des contrôles effectués fournissent une base appropriée pour s’appuyer sur les contrôles ;
b)     si des tests additionnels des contrôles sont nécessaires ;
c)     si les risques d’anomalies significatives exigent la mise en œuvre de procédures de corroboration. »

Le membre ajoute que si à la suite de ces procédures nous concluons que le contrôle ne fonctionne pas correctement, le niveau de risque lié au contrôle doit être augmenté au niveau maximum. Des procédures de corroboration devront être effectuées selon la méthodologie du cabinet. Le nombre de tests dépend du risque d’anomalie significative qui a été évalué.

Les membres du groupe de travail ont élaboré deux exemples qui pourraient arriver en pratique. 

Premier exemple

Contrôle d’application : Pour ce client, les contrôles généraux informatiques (CGI) fonctionnent. Cependant, pour une application donnée, des problèmes (erreurs) ont été relevés. Il y a une formule de calcul de coût moyen pour l’inventaire et l’auditeur a détecté une erreur dans cette formule. Il s’agit ici d’un problème de contrôle d’application. Le praticien explique que dans ce type de situation, l’auditeur tente de trouver un contrôle compensatoire. Si aucun contrôle compensatoire n’existe, la situation devient problématique et nécessite du travail supplémentaire. 

Dans chaque cas, il faut comprendre la déficience. Subséquemment, des procédures de corroboration additionnelles seront requises en fonction de la déficience pour répondre à cette dernière. Par exemple, si l’auditeur constate que la population n’est pas complète (déficience), il testera, à l’aide de procédures de corroboration additionnelles, la partie manquante. En pratique, cette situation est plus claire que la situation inverse (les contrôles d’application fonctionnent, mais les CGI ne fonctionnent pas. Voir le compte-rendu 1, question 3). Dans le dernier cas (formule de calcul du coût moyen pour l’inventaire), l’auditeur doit tester les contrôles d’application comme un contrôle manuel. Il serait possible également de faire des procédures alternatives. 

Deuxième exemple (élaboré en collaboration avec un auditeur TI¹)

Contrôle automatisé applicatif

Contexte : Pour ce client, les contrôles généraux informatiques (CGI) fonctionnent et ont été testés. Cependant, pour une application donnée, des problèmes (erreurs) ont été relevés sur le plan d’un contrôle automatisé applicatif. 
Problème : À titre d’exemple, il existe une interface automatisée entre le système de point de vente (POS) et le système comptable qui effectue un transfert, en fin de journée, de l’ensemble des transactions de ventes réalisées. L’auditeur a détecté un manquement dans la transmission des ventes pour une journée donnée (via le processus d’alerte par notification). Il s’agit ici d’un problème de contrôle automatisé applicatif. 

Cause : Le praticien explique que dans ce type de situation, l’auditeur tente de trouver dans un premier temps la cause sous-jacente à la déficience du contrôle soulevée. Dans ce cas-ci, s’agit-il d’un cas isolé et circonscrit à une seule journée? S’agit-il, par exemple, d’un problème de connexion Internet ayant empêché le transfert adéquat des informations de vente pour la journée? Le transfert des informations de vente a-t-il tout de même eu lieu, mais à un moment ultérieur, par exemple le lendemain? La compréhension de la cause associée à la déficience (non-exhaustivité des ventes) aidera à déterminer s’il s’agit d’un problème sporadique ou bien si la déficience est un symptôme associé à une cause plus grave, c’est-à-dire, par exemple, la mauvaise configuration des alertes de notification associées à l’interface ou encore une mauvaise configuration de l’interface elle-même. 

Analyse : 
a) Si dans l’exemple, l’auditeur fait face à la situation où le transfert des ventes via l’interface informatique a eu lieu à un moment ultérieur en raison d’une mauvaise connexion Internet, il pourra alors avoir recours à des procédures additionnelles d’audit telles que vérifier les transferts des journées précédentes et subséquentes en comparant manuellement les totaux de ventes selon le système de point de vente versus les totaux du système comptable pour chaque journée sélectionnée. Il devra alors vérifier que le transfert s’est effectué de façon adéquate et auditer l’exhausvitité des ventes et autres assertions pertinentes.

b) Si dans l’exemple, l’auditeur relève que les alertes notifiant l’échec du transfert via l’interface ne sont pas adéquatement configurées, il pourrait alors procéder à des tests corroboratifs additionnels, car il se peut que les alertes de notifications soient déficientes du point de vue de leur configuration, mais que le transfert des ventes intersystème ait tout de même eu lieu.

c) Si dans l’exemple, l’auditeur relève que l’interface en elle-même est mal configurée et que certains transferts de totaux de ventes ne sont pas effectués, et ce de façon répétitive, il pourrait alors remettre en doute la validité des contrôles généraux informatiques supportant l’application informatique (par exemple, une erreur dans le développement de l’interface et la non-détection de la défaillance lors des tests de mise en production de ladite interface). Ce faisant, l’auditeur devra revoir sa stratégie à l’égard des ventes.

Chaque fois, l’auditeur doit vérifier si un ou des contrôles compensatoires existent. Si aucun contrôle compensatoire n’existe, la situation devient problématique. Dans chaque cas, il faut comprendre adéquatement la déficience et son impact. Subséquemment, des procédures additionnelles d’audit seront requises en fonction de la nature de la déficience.

¹ Il existe certains référentiels (TI) permettant de guider les praticiens dans des contextes similaires. L’analyse a été développée autour de ces référentiels.

2) Comment gérer le volet informatique concernant les rapports sur lesquels on s’appuie? 

• Il semble y avoir beaucoup de diversité en pratique et la norme n’est pas directive sur cet aspect particulier.

Un membre fait référence à la NCA 315. Annexe 5.10 où il est mentionné que « L’auditeur peut vouloir utiliser comme éléments probants des rapports générés par le système, tel que des balances chronologiques des créances clients ou des rapports d’évaluation des stocks. Afin d’obtenir des éléments probants sur l’exhaustivité et l’exactitude de tels rapports, l’auditeur peut mettre en œuvre des procédures de corroboration portant sur leurs données d’entrée et de sortie. Dans d’autres cas, il peut avoir l’intention de tester l’efficacité du fonctionnement des contrôles afférents à la préparation et la mise à jour de ces rapports, auquel cas l’application informatique qui génère les rapports fera probablement partie des applications vulnérables aux risques découlant du recours à l’informatique. En plus de tester l’exhaustivité et l’exactitude des rapports, l’auditeur peut également prévoir de tester l’efficacité du fonctionnement des contrôles généraux informatiques visant à répondre aux risques de modification non autorisée ou inappropriée des programmes ou des données sous-tendant les rapports. »

Un membre affirme que la première étape est la compréhension de l’environnement informatique afin de bien comprendre comment sont générés les rapports. Il faut également tenir compte des conclusions spécifiques relatives aux contrôles généraux informatiques supportant lesdits rapports. Des conclusions amenant l’auditeur à douter, soit de la façon dont les rapports sont configurés ou que les données que ceux-ci contiennent peuvent avoir été manipulées. devraient être considérées avec la plus haute diligence avant de décider de s’appuyer sur ces rapports. Il pourrait même être pertinent de réaliser des tests sur ces derniers. 

Dans la situation où un appui sur les rapports générés par les systèmes est possible, les tests sur les rapports dépendront du type de logiciel utilisé ainsi que de la complexité du rapport ; des rapports standards provenant de systèmes commerciaux (personnalisables ou non) ou des rapports développés à l’interne peuvent exister. Peu importe la complexité des rapports, il faut tester l’exactitude et l’exhaustivité de ces derniers. Les façons présentées ci-dessous sont de bons exemples pour réaliser ces tests.

1. Un rapport peut être testé en corroborant les données d’entrée et de sortie. Par exemple, un rapport d’exception sur les prêts financiers pourrait être testé en ajoutant un prêt au système (saisie dans l’application) correspondant à des critères d’anomalie (par exemple un prêt n’ayant pas de date d’échéance ou de taux d’intérêt associé) et en vérifiant que celui-ci apparaît bel et bien sur le rapport d’exception. Le test inverse peut aussi être fait, c’est-à-dire ajouter un prêt au système (saisie dans l’application) ne présentant aucune anomalie et vérifier que celui-ci ne figure pas au rapport d’exception. Des tests positifs et négatifs sont toujours recommandés pour bien tester les rapports. L’auditeur pourrait également demander de valider la configuration dudit rapport ainsi que des règles d’anomalies sous-jacentes permettant l’identification des exceptions. Les tests sur les rapports doivent pouvoir démontrer que ceux-ci sont adéquatement configurés pour contenir et présenter une information fiable, complète et exacte sur laquelle l’auditeur pourra s’appuyer.
2. Un rapport peut être testé en corroborant ses paramètres d’extraction et son résultat final. Par exemple, un rapport sur les ventes du mois de juin, pourrait être testé en s’assurant qu’à la suite de la sélection du paramètre du mois de juin, le rapport contient uniquement la liste des transactions de ventes du mois de juin, mais également que le montant total des ventes pour le mois de juin correspond véritablement à ce que l’on retrouve au grand livre pour cette même période.
3. Des sources externes peuvent également être utilisées pour valider les données contenues dans un rapport. Un autre exemple de test : un registre de paie pourrait être comparé à une fiche salariale d’employé ou une lettre d’embauche afin de corroborer que le salaire indiqué au rapport est adéquat, donc que le rapport prend en considération le bon employé et la bonne donnée salariale correspondante.  

Toujours en lien avec les tests sur les rapports provenant des systèmes, un autre membre ajoute que sa méthodologie exige l’exécution d’une seule ou d’une combinaison des procédures qui suivent :

1. Faire un examen indépendant du code informatique (ex. : de la requête SQL).
2. Refaire le ou les rapports en se servant d’un extrait des données de base.
3. Faire des tests de détail des attributs pertinents. Il s’agit de tests acceptation-rejet. La méthodologie du cabinet comprend des « tables » pour déterminer le nombre de tests à effectuer en fonction du nombre d’écarts acceptables et du niveau de fiabilité qu’ils désirent obtenir (faible, moyen ou élevé).
4. Effectuer un test indépendant, c’est-à-dire s’assurer qu’une ou des données de base se sont bien reportées dans le rapport.

Un praticien rappelle que, dans certains cas, le rapport est généré à l’extérieur du système comptable. Certains de ces rapports sont complexes et particuliers. Il est important de vérifier comment l’interface fonctionne entre le système comptable et le système de production du rapport. Il est également important de porter son attention sur la provenance de l’information ainsi que sur les liens entre les interfaces. Enfin, il est fondamental de comprendre si le rapport à la suite de son extraction a été manipulé ou personnalisé afin d’obtenir l’information requise. Auquel cas, l’auditeur devra prendre cet aspect en considération lors des tests. 

Un membre précise que la discussion précédente porte sur des rapports sur lesquels les auditeurs s’appuieront pour obtenir des éléments probants. Mais il est aussi possible que la direction s’appuie sur des rapports pour effectuer des contrôles manuels. Si l’auditeur s’appuie sur ces contrôles, il devra alors tester ces rapports de la même façon que vu précédemment. 

3) Est-ce possible d’éviter les aspects TI de l’audit et se tourner vers de la corroboration pure? 

• Dans quelle(s) situation(s), il n’est pas nécessaire de tester les aspects TI?

Un membre mentionne que la documentation et la compréhension de l’environnement CGI sont des étapes incontournables. On ne peut donc pas, selon lui, éviter complètement les aspects TI. Il est peut-être possible de tester la mise en place de très peu de contrôles informatiques généraux selon le cas, mais il devrait toujours y avoir un minimum de documentation et de tests de mise en place sur les CGI. Pour les applications, il faut également une documentation minimale avec des tests de mise en place si les contrôles informatiques touchent une assertion pertinente pour un risque important. Encore là, il lui semble impossible d’éviter complètement l’aspect TI. 

Un autre membre ajoute qu’il rejoint le point mentionné dans le paragraphe ci-dessus. Selon le par. 26, la compréhension et les tests de mise en place des activités de contrôles, incluant les CGI pertinents, sont requis pour :

• les contrôles visant à répondre aux risques identifiés comme des risques importants ;
• les contrôles afférents aux écritures de journal ;
• les contrôles dont l’auditeur prévoit de tester l’efficacité du fonctionnement en vue de déterminer la nature, le calendrier et l’étendue des procédures de corroboration, ce qui doit inclure les contrôles visant à répondre aux risques pour lesquels les procédures de corroboration ne peuvent fournir à elles seules des éléments probants suffisants et appropriés ;
• les autres contrôles qui, selon le jugement professionnel de l’auditeur, sont appropriés pour permettre à celui-ci d’atteindre les objectifs énoncés au paragraphe 13 en ce qui a trait aux risques au niveau des assertions.

Seul le troisième aborde l’aspect des tests du fonctionnement efficace des contrôles. Par conséquent, même en approche purement corroborative, la compréhension des CGI pertinents et les tests de mise en place sont requis. Toutefois, il est important de mentionner que le mot « pertinents » est clé dans le libellé de la norme.  

Un membre aborde le fait que les stratégies dépendront grandement des clients et de leurs environnements respectifs. À titre d’exemple, si deux clients différents utilisent le même système comptable standardisé et que l’auditeur utilise une stratégie corroborative, les CGI pourraient être gérés de façon différente ce qui influencerait les stratégies utilisées. La possibilité que d’autres logiciels puissent intervenir ou que les CGI entourant ces logiciels diffèrent pourrait entraîner une stratégie d’audit et un nombre de tests de corroboration différents. 

Lorsque les stratégies corroboratives seront utilisées, un membre ajoute qu’un travail minimum devra être fait au niveau des TI, et ce, même si les systèmes sont relativement simples. Cela s’explique par la présence des écritures de journal qui causeront la nécessité de tester les CGI relatifs aux accès. Le praticien donne un exemple qui devrait être rare en pratique : un système commercial, non personnalisable et dans lequel l’auditeur arrive à la conclusion que les autres aspects des CGI ne sont pas pertinents dans le cadre de l’audit. Par exemple, une comptabilité produite dans Excel dans un petit OSBL pour un « caisse/déboursé ». 

Le membre précise également que ce n’est pas parce que l’on affirme que l’aspect TI doit être compris et que la mise en place doit être testée que cela nécessite automatiquement l’intervention d’un expert TI. Certains travaux peuvent être faits par l’équipe de mission même si cela touche des aspects TI. 

Activités de contrôle

4) Le paragraphe 26 a) i) exige de recenser les activités de contrôles répondant aux risques importants. Or, pour arriver à identifier les risques importants, l’auditeur doit obtenir une compréhension minimale de la composante du contrôle interne « activités de contrôle » liées à chacun des processus significatifs. 

• Concrètement, comment l’auditeur doit-il s’y prendre pour répondre à cette exigence de la norme? Est-ce qu’il doit faire une analyse préliminaire des risques pour les besoins du recensement des activités de contrôle?

Les activités de contrôle représentent une composante du système de contrôle interne de l’entité. Le paragraphe 26 exige une compréhension minimale de cette composante, peu importe l’évaluation du risque lié au contrôle et la stratégie d’audit. 

D’ailleurs, l’auditeur doit prendre connaissance du système de contrôle interne de l’entité avant de procéder à l’identification et à l’évaluation des risques inhérents et liés au contrôle. En fait, c’est cette prise de connaissance jumelée à la prise de connaissance de l’entité et de son environnement, du référentiel applicable et des autres composantes du système de contrôle interne qui alimentera l’identification et l’évaluation des risques. 

Selon les membres, l’auditeur doit se rappeler que le processus d’identification et d’évaluation est un processus itératif. L’auditeur peut se baser sur son évaluation des risques de l’an dernier en plus de la mise à jour de sa connaissance de l’entité pour déterminer quels sont les risques importants pour lesquels des activités de contrôle doivent être identifiées. La conception et la mise en place de ces activités de contrôle devront être testées. Si jamais de nouveaux risques importants étaient relevés plus tard au cours de l’audit, l’auditeur devra s’assurer de relever des activités de contrôle afin de respecter le paragraphe 26 de la NCA 315.

5) Concernant les CGI d’un client, quelles seraient des exemples de circonstances qui entraîneraient une réserve ou une impossibilité d’émettre une opinion?

Réserve

Un membre donne comme exemple un client pour lequel une certaine application ne pourrait pas être testée. Cette application serait développée par un fournisseur externe et le client n’aurait pas de droit d’accès. Il ne serait également pas possible d’obtenir un rapport selon le Chapitre 3416. Si le problème est circonscrit à cette application en particulier, il serait possible de cibler les répercussions de cette limitation. 

Bref, dans les cas où la limitation touche seulement un cycle, la réserve serait pertinente.  

Un second exemple est donné pour un client qui se spécialise dans la vente en ligne lorsque l’auditeur serait dans l’incapacité d’obtenir un rapport selon le Chapitre 3416. Ici, le cycle de ventes est identifiable et il est possible de circonscrire l’incidence.

Un autre exemple est cité : une entreprise qui utilise un système de paye maison développé par un développeur externe et pour lequel nous n’avons pas l’accès pour effectuer des tests de systèmes. 

La réserve au rapport pourrait donc être requise dans certaines situations où l’auditeur est confronté à un problème d’accès ou une incapacité de tester (incapacité technique). Cette situation sera bien entendu indépendante des demandes ou réticences d’un client.

Impossibilité d’exprimer une opinion

Un membre donne comme exemple que dans un environnement hautement informatisé, un client refuse que l’auditeur teste ses CGI. Dans ce type de circonstance, le système comptable est directement affecté par les CGI. Le fait que l’environnement soit hautement informatisé laisse penser que les procédures de corroboration à elles seules ne sont pas suffisantes. Conséquemment, les contrôles devront être testés. Il est difficile de ne pas prendre en considération les contrôles informatiques dans un environnement hautement informatisé. Un autre membre ajoute que dans le cas des environnements hautement informatisés, si, à la suite de notre analyse, la seule manière d’obtenir de l’assurance dépend des TI et que le client nous refuse l’accès, un questionnement portant sur la transparence et l’honnêteté du client devra être soulevé.

Selon un membre, un client qui refuse que l’auditeur teste ses CGI devrait amener l’auditeur à avoir un esprit critique en alerte. Le fait que le client refuse, pour une question de coût ou autre, ne se qualifierait pas comme une situation de réserve au rapport. Un autre membre affirme que la réserve ne devrait pas être une façon d’éviter l’application de la norme. 
 
La réserve n’est pas possible si le cabinet n’est pas en mesure de réaliser une portion de l’audit dû à un manque de connaissance ou de compétences. Si le client refuse l’accès pour une raison de coûts, il ne s’agit pas d’une raison acceptable pour justifier une réserve. Un membre ajoute que nous devons nous questionner si nous pouvons accepter ce type de mission lorsque le client ne veut pas payer pour un expert TI, pour un rapport selon le Chapitre 3416 ou pour tout autres types de travail. 

6) Un client refuse les démarches permettant d’obtenir un rapport selon le Chapitre 3416. Quelle en sera l’incidence sur l’audit?

Un membre mentionne qu’il est important de comprendre la raison du refus du client. Il ajoute que cette situation s’est produite dans sa pratique. Il a donc communiqué avec le conseil d’administration afin de conscientiser les administrateurs sur leurs responsabilités de s’assurer que l’information financière soit bonne et exacte. Si ces derniers s’appuient sur une entreprise de service pour générer de l’information, ils devraient être dans leur intérêt de savoir si les contrôles internes chez cette société de service sont bien mis en place et fonctionnels. Il y a un objectif relatif à l’audit pour les auditeurs, mais il y a également un intérêt pour les administrateurs d’avoir ce rapport 3416. Cela permet de les rassurer sur la fiabilité de l’information. Dans l’exemple mentionné, après cette discussion, le client a accepté de demander ce rapport 3416. 

Si après cette discussion, le client maintient son refus, nous vous référons à la question précédente de ce document.

Voici d’autres éléments et questions à considérer mentionnés par d’autres membres. 

Un membre mentionne qu’il est parfois possible de faire des procédures alternatives. Par exemple, pour un relevé de placement d’un courtier pour lequel un rapport 3416 n’est pas disponible. La procédure alternative serait d’utiliser une tierce partie pour aller corroborer les valeurs marchandes des placements. 

D’une manière générale, un membre s’exprime sur les difficultés vis-à-vis les rapports 3416 qu’on obtient des organismes de services dans la pratique. Par exemple, les rapports 3416 qui ne couvrent pas la même fin d’exercice que le client, la difficulté d’obtenir ce type de rapport, le moment où l’auditeur reçoit le rapport, la difficulté d’interprétation et enfin que ce soit les bons objectifs/éléments que l’auditeur veut couvrir.