3072 Documentation des travaux réalisés au moyen de solutions technologiques lors d’un audit
juin-2020

Aperçu

La présente section traite des points suivants :

  • la documentation de l’utilisation d’une technologie ainsi que des procédures mises en œuvre et, s’il y a lieu, de la logique appliquée par la technologie;

  • la conservation des données du client utilisées par les solutions technologiques;

  • des exemples pratiques de documentation de l’utilisation de solutions technologiques.

Directives du BVG

Les travaux réalisés au moyen de solutions technologiques sont documentés et conservés conformément aux exigences de la section BVG Audit 1100. Voici des exemples de solutions technologiques :

  • les techniques d’audit assistées par ordinateur (TAAO);

  • les techniques d’audit des données, l’automatisation et la visualisation à l’aide de technologies comme Excel ou IDEA;

  • les solutions créées avec IDEA, Python, R, SAS ou d’autres technologies, y compris des solutions utilisées pour tester les configurations des systèmes informatiques ou les réglages de sécurité.

Les exigences en matière de documentation s’appliquent, peu importe si c’est un membre de l’équipe de mission qui a conçu la solution ou effectué les travaux, ou bien des spécialistes, comme ceux de l’Équipe d’analyse des données et des méthodes de recherche, des spécialistes de la comptabilité ou des spécialistes de l’audit.
Lorsque l’auditeur met en œuvre des procédures en utilisant des solutions technologiques, il documente dans le dossier d’audit les éléments suivants :

  • L’étendue et l’objectif des travaux qui seront réalisés, y compris les risques d’audit qui seront traités. Si un expert choisi par l’auditeur ou un spécialiste de la comptabilité ou de l’audit effectue les travaux, les membres de l’équipe de mission doivent discuter de l’étendue et de l’objectif des travaux avec l’expert ou le spécialiste afin d’obtenir une compréhension des travaux et de documenter ceux-ci, ou d’examiner la documentation des travaux. La documentation comprend :

    • l’étendue des tests (p. ex. consolidation, jeu précis de documents comptables, codes d’entités ou d’entreprises);

    • les systèmes ou les sources de données utilisés dans le cadre des procédures d’audit. Par exemple :

      • le niveau auquel les tests sont effectués (p. ex. consolidation, grand livre général, grand livre auxiliaire) lorsqu’une solution technologique est utilisée;

      • les fonctionnalités et les attributs particuliers des contrôles qui seront visés (configurations de système, paramètres de sécurité des applications, etc.) par le test des contrôles internes de l’entité (contrôles du traitement de l’information et/ou CGI);

    • les procédures particulières qui seront mises en œuvre et les dates d’audit.

  • Une description des travaux réalisés, y compris :

    • les procédures mises en œuvre pour évaluer l’exactitude et l’exhaustivité des informations utilisées dans le cadre des procédures;

    • les procédures mises en œuvre, y compris la nature, le calendrier, l’étendue et les résultats des tests (et les écarts), le nom des personnes qui ont réalisé et revu les travaux et les dates auxquelles les travaux ont été faits et passés en revue;

    • les procédures mises en œuvre et/ou la logique appliquée pour produire les résultats;

    • la description des fichiers originaux de l’entité utilisés et la source des données (p. ex. la personne, le système et la date de réception);

    • un résumé de l’analyse et des constatations;

    • toute mesure de suivi exigée par l’équipe de mission (si les travaux ont été réalisés par un spécialiste de la comptabilité ou de l’audit, ou par un expert choisi par l’auditeur);

    • tout changement ou ajout apportés à l’étendue originale des travaux, le cas échéant.

Documentation de l’utilisation d’une technologie ainsi que des procédures mises en œuvre et/ou de la logique appliquée par la technologie

L’auditeur dispose de diverses méthodes pour documenter les procédures mises en œuvre et/ou la logique appliquée pour produire des résultats au moyen d’une solution technologique, notamment :

  • Documenter le résultat de la technologie, qui comprend les formules ou d’autres critères (p. ex. tri, filtrage) utilisés pour exécuter les procédures (p. ex. inclure la feuille de travail Excel).

  • Joindre le script ou le programme (p. ex. SAS, SQL, IDEA Script, aperçu de projet IDEA [tableau et diagramme] ou historique IDEA) ou une exportation du flux de travaux du logiciel analytique, le résultat de la visualisation ou toute autre logique de système au dossier d’audit.

  • Ce faisant, si les formules, les critères ou la logique sont complexes, l’auditeur évalue si le réviseur ou « un auditeur expérimenté et n’ayant pas jusqu’alors participé à la mission » serait en mesure de comprendre les procédures mises en œuvre. Dans certains cas, il peut être nécessaire de joindre des explications en « langage simple » au flux de travaux, à la visualisation ou à la logique du script pour simplifier la revue. Pour ce faire, l’auditeur pourrait, par exemple, ajouter des boîtes de texte au-dessus de chaque fonction exécutée dans le flux de travaux pour expliquer en langage simple ce que la fonction fait et joindre le flux de travaux aux feuilles de travail.

  • Consigner « en langage simple » les procédures exécutées par la technologie. Par exemple, lorsqu’un script est utilisé pour effectuer certaines procédures, l’auditeur peut inscrire la note suivante : « IDEA est programmé afin d’extraire [p. ex. une liste de modalités de prêts] du contrat sous-jacent, de remplir automatiquement la feuille de calcul avec chaque modalité et le montant correspondant dans une autre colonne et de calculer la différence entre le solde selon le système de la direction dans la colonne C et le montant produit par IDEA dans la colonne D ».

  • Inclure des marques de pointage dans les feuilles de travail qui expliquent où et comment les montants ont été obtenus ou calculés.

  • Il y a deux façons de documenter l’utilisation d’une visualisation pour mettre en œuvre une procédure d’audit : 1) exporter des captures d’écran des visualisations et les insérer dans le dossier d’audit; 2) conserver la visualisation proprement dite (p. ex. fichier .idash dans IDEA). L’auditeur tient compte de la complexité de la visualisation pour choisir la méthode appropriée. Plus il y a de filtres, de formules et d’autres critères qui sont utilisés pour reconfigurer les jeux de données sous-jacentes, plus il est probable que la conservation du fichier de visualisation soit nécessaire pour satisfaire aux exigences en matière de documentation.

Si les procédures mises en œuvre au moyen de la technologie sont complexes (p. ex. les procédures peuvent comprendre un grand nombre d’intrants, de corrélations entre les intrants ou d’itérations d’un calcul), l’auditeur exécute généralement des transactions d’essai dans le flux de travaux ou le robot logiciel pour tester à la fois les conditions positives et négatives, ainsi que les diverses permutations et conditions, au besoin, et pour vérifier si la technologie fonctionne comme prévu. Toutefois, de tels essais pour vérifier si la technologie fonctionne comme prévu ne sont généralement pas nécessaires si la solution technologique est un outil approuvé. L’auditeur documente les essais effectués et/ou conserve la documentation des transactions d’essai et les résultats dans le dossier d’audit.

La nature et l’étendue des procédures et de la documentation afférente doivent être proportionnelles au risque d’anomalies significatives évalué et à l’importance de cette procédure pour la stratégie et le plan d’audit. Plus le risque évalué et la complexité sont élevés, et plus la procédure d’audit est importante, plus l’étendue de la documentation doit aussi être grande.

Ces principes de documentation s’appliquent également lorsqu’un tableur, comme Excel de Microsoft, est utilisé comme solution technologique dans le cadre d’un audit. En outre, lorsque l’auditeur utilise Excel pour examiner, trier, filtrer ou analyser des données, il doit envisager d’utiliser la fonction de commentaire pour y consigner en « langage simple » la nature des fonctions ou des formules utilisées dans Excel. De même, si un code Visual Basic est utilisé, l’auditeur envisage d’utiliser la fonction de commentaire dans Visual Basic Editor (« VBE ») pour consigner en « langage simple » la nature du comportement du programme Visual Basic. Il indique alors dans la feuille de travail Excel que cette information a été ajoutée dans VBE.

En plus des considérations relatives à la documentation, les exigences liées à la supervision et à la revue sont interdépendantes et doivent être examinées ensemble lorsque l’auditeur apprécie si la technologie utilisée est appropriée dans les circonstances et détermine la nature et la quantité des éléments qui doivent être documentés dans les feuilles de travail. Se reporter à la section BVG Audit 3073 pour connaître les considérations relatives à la supervision et à la revue lors de l’utilisation de solutions technologiques.

Considérations relatives à la documentation de l’utilisation d’un outil approuvé

Dans les cas où l’auditeur se sert d’une solution technologique approuvée par le Bureau, il documente la façon dont l’outil a été utilisé et les données de sorties afférentes, mais il n’a pas besoin de documenter la logique de l’outil. Par exemple, si l’auditeur utilise IDEA Script pour analyser de grands livres généraux et que cet outil est approuvé pour les missions, il n’a pas besoin de consigner le code et la logique du logiciel dans la base de données de la mission. Le Bureau est responsable de la fiabilité des outils approuvés, car on s’attend à ce que la documentation soit conservée de manière centralisée. L’équipe de mission n’a donc pas besoin de reproduire cette documentation.

Conservation des données du client utilisées par des solutions technologiques

En général, les données obtenues auprès de l’entité qui n’ont pas besoin d’être conservées conformément à la NCA 230 et au Manuel d’audit annuel du BVG (voir les sections BVG Audit 1110 et BVG Audit 1121) ne sont pas conservées après l’achèvement de la mission. Toutefois, il pourrait s’avérer nécessaire d’utiliser des données déjà fournies par l’entité, notamment pour l’audit d’un exercice postérieur, par exemple lors de :

  • l’exécution d’analyses des tendances portant sur plus d’une période de données;

  • la simplification du regroupement par l’entité de données de l’exercice postérieur;

  • la formation de nouveaux membres de l’équipe de mission afin qu’ils puissent acquérir une compréhension des nuances dans les données.

Comme le veut la pratique courante, il est important de s’assurer que la documentation de l’audit est compilée de façon adéquate lors de la période de constitution du dossier définitif et qu’elle est supprimée des supports de stockage temporaire dans un délai de 60 jours. Tous les documents d’audit qui étayent des conclusions d’audit doivent être conservés dans le logiciel de gestion des feuilles de travail. Il est de bonne pratique d’aviser le client que les données qu’il a fournies seront supprimées, conformément à notre politique, et que nous pourrions lui demander les mêmes données plus tard pour d’autres travaux d’audit. S’il n’est pas prévu de conserver les données obtenues auprès de l’entité, la procédure effectuée à l’aide de données du client doit être documentée de façon à donner suffisamment de détails sur les données utilisées (p. ex. le nom, la date et tout autre paramètre pertinent du rapport du client ou de la requête servant à produire les données utilisées dans le cadre de la procédure). Que les données soient conservées ou non, l’auditeur documente les procédures mises en œuvre pour vérifier la fiabilité des données conformément à la section BVG Audit 4028.4.

Se reporter à la section BVG Audit 3101 pour consulter les considérations relatives à la conservation des données lorsque les travaux sont réalisés par des spécialistes de la comptabilité ou de l’audit.

Exemples pratiques de documentation de l’utilisation de solutions technologiques

Les exemples ci-après mettent l’accent sur certains facteurs pertinents que l’auditeur prend en considération lorsqu’il pose des jugements importants sur :

  • la façon de documenter les procédures mises en œuvre et la logique appliquée par la technologie;
  • la documentation nécessaire pour appuyer la supervision et la revue.

Ces exemples ne comprennent pas d’autres types de documentation généralement compris dans les feuilles de travail, comme la documentation servant à corroborer l’exhaustivité et l’exactitude des documents sources.

Exemple 1

Un membre de l’équipe utilise IDEA pour tester l’exactitude mathématique du grand livre auxiliaire des comptes clients, recenser les éléments inhabituels selon l’équipe d’audit, comme les soldes créditeurs, déterminer les éléments à valeur élevée qui feront l’objet de tests ciblés, et additionner le solde restant qui fera l’objet d’un sondage non statistique.

Documentation

La documentation contiendrait ce qui suit : les types d’éléments qui, selon l’équipe de mission, sont inhabituels; les éléments qui ont bel et bien été recensés; une description des éléments ciblés (p. ex. toutes les factures supérieures à 1 million de dollars); la valeur des montants des créances clients ciblés; et la valeur du montant cumulé des soldes des créances clients restants visés par le sondage non statistique. La documentation comprendrait aussi les fonctions dans IDEA qui ont été utilisées pour réaliser ces activités (remarque : les fonctions se nomment des « tâches » dans IDEA). En voici un exemple : « Les factures supérieures à 1 million de dollars ont été sélectionnées au moyen de l’outil d’extraction directe d’IDEA ». Par ailleurs, pour documenter les travaux, le préparateur peut aussi incorporer le diagramme et le tableau d’aperçu de projet d’IDEA ou l’historique complet d’IDEA et, le cas échéant, les équations ou les définitions d’importation utilisées dans le dossier d’audit. Étant donné que cette analyse pourrait être utilisée dans le cadre d’un audit d’un exercice postérieur, la conservation des équations ou des définitions d’importation d’IDEA pourrait accroître l’efficience des travaux futurs.

Supervision et revue

Le responsable de la revue devrait comprendre les procédures effectuées par chacune de tâches et équations d’IDEA utilisées dans le cadre de l’analyse, y compris les filtres appliqués, pour produire les résultats et il effectuerait une revue de l’analyse pour déterminer si elle a été conçue de manière à atteindre l’objectif prévu.

Exemple 2

Un robot logiciel personnalisé est conçu et élaboré par une équipe de mission pour automatiser la comparaison de deux feuilles de calcul Excel (utilisateurs supprimés du système de grand livre général au cours de la période et la liste actuelle des utilisateurs du grand livre général) afin de déceler les écarts éventuels, à savoir si un utilisateur supprimé a encore accès au système. Le robot logiciel est programmé pour accéder aux fichiers Excel, insérer une formule standard d’Excel (RECHERCHEV) pour apparier les identifiants et les noms d’utilisateur entre deux feuilles de calcul et signaler les utilisateurs figurant dans les deux rapports, ce qui indique que l’accès de l’utilisateur aurait dû être retiré, mais que cela n’a pas été fait.

Documentation

Les procédures que le robot logiciel a exécutées sont documentées par le préparateur dans les feuilles de travail selon une des méthodes de documentation décrites dans la présente section (une exportation de la logique du robot logiciel ou une description en langage simple des actions du robot logiciel). La documentation qui doit être constituée pour cet exemple diffère de la documentation nécessaire si seulement la formule RECHERCHEV dans Excel avait été utilisée pour effectuer le test (c.-à-d. sans le robot logiciel qui accède aux fichiers pour y insérer la formule RECHERCHEV), parce que la formule en question pourrait être facilement examinée directement dans la feuille de calcul Excel comprise dans les feuilles de travail.

Supervision et revue

Le responsable de la revue devrait examiner l’extrant du robot logiciel dans le contexte des procédures d’audit effectuées ainsi que les intrants dans le robot logiciel. Il doit notamment vérifier que les bonnes données sources et les bons paramètres (p. ex. période de temps) ont été utilisés et vérifier l’exhaustivité et l’exactitude des procédures mises en œuvre à l’égard des données sources. Il est également responsable d’examiner les procédures mises en œuvre pour comprendre et évaluer la fonctionnalité du robot logiciel, y compris si les procédures exécutées par le robot sont appropriées pour atteindre l’objectif prévu.

Exemple 3

Une visualisation créée par l’équipe de mission au moyen d’IDEA est utilisée pour déterminer la période avant et après la date de clôture qui servira à tester la séparation des périodes pour les ventes/créances clients. La visualisation illustre les volumes des ventes au titre de chaque flux de rentrées à auditer pour chaque jour du dernier mois de l’exercice considéré et chaque jour du premier mois de l’exercice suivant, et ce, pour tous les flux de rentrées de l’entité.

Documentation

Les feuilles de travail doivent comprendre une brève description de la visualisation, y compris les calculs que le préparateur a appliqués directement dans IDEA. Ces informations sont assorties soit d’une exportation de la visualisation (p. ex. une capture d’écran en format PDF ou un document PDF), soit du fichier IDEA (.idash) dans le dossier d’audit. Étant donné que la formule appliquée est relativement simple (c.-à-d. 30 jours avant et 30 jours après la date de clôture), l’inclusion d’une exportation de la capture d’écran qui documente cette formule serait probablement suffisante pour satisfaire aux exigences en matière de documentation.

Supervision et revue

Le responsable de la revue devrait passer en revue le résultat de la visualisation dans le contexte des procédures mises en œuvre et déterminer si les filtres et les mesures appliqués et les calculs utilisés étaient appropriés pour atteindre l’objectif prévu. Il devrait également comprendre les filtres appliqués, en évaluant l’objectif des filtres et en déterminant si toutes les données pertinentes ont été incluses et si l’une de ces considérations pourrait modifier les conclusions tirées.

Foire aux questions

Q1. Quelle information faut-il consigner dans le dossier d’audit lorsque l’auditeur utilise la tâche de Doublons approximatifs dans IDEA?

R1. La tâche de Doublons approximatifs (Fuzzy Duplicate) dans IDEA peut servir à recenser des correspondances inexactes ou des doublons non identiques dans un jeu de données en précisant un mot clé et un seuil de degré de similitude exprimé en pourcentage. Les degrés de similitude des correspondances ont seulement besoin de se situer à l’intérieur des seuils précisés par l’utilisateur ou des seuils établis par défaut au moyen des paramètres de configuration. Un seuil plus élevé produit des degrés de similitude plus élevés (c.-à-d. moins de variabilité entre l’intrant et les « groupes de correspondance » recensés) ce qui produit un nombre moins élevé de « groupes de correspondance ». Inversement, des seuils moins élevés produisent des degrés de similitude moins élevés (c.-à-d. une plus grande variabilité entre l’intrant et les « groupes de correspondance » recensés) ce qui augmente le nombre de « groupes de correspondance ».

La tâche Doublons approximatifs dans IDEA est comparable à la recherche floue (Fuzzy Lookup) dans Excel et permet à un utilisateur de recenser des correspondances inexactes dans les données. En précisant un seuil de degré de similitude en pourcentage (la valeur par défaut dans IDEA est de 80 %), au moyen de divers algorithmes d’appariement et d’autres options de configuration, l’utilisateur peut personnaliser l’outil en fonction du jeu de données et de l’objectif d’appariement. Il faut noter qu’un identifiant unique pour chaque enregistrement de données est nécessaire pour que la tâche Doublons approximatifs fonctionne dans IDEA.

Lorsque l’équipe de mission utilise la tâche Doublons approximatifs dans IDEA, elle doit fixer le seuil d’appariement à un niveau qui concorde avec l’objectif d’appariement des données. Elle doit documenter la justification pour le seuil d’appariement choisi. Par exemple, pour recenser des opérations entre parties liées, l’équipe de mission peut prévoir d’utiliser la tâche Doublons approximatifs dans IDEA pour analyser le journal des décaissements afin de recenser les paiements versés aux parties liées. Si l’équipe de mission a entré le mot clé « Société de camouflage » et établi un seuil d’appariement de 95 %, des variations comme « Société de camoflage » ou « Société de camoflague » pourraient faire partie des résultats, mais la recherche ne trouverait pas des variations comme « so de comoflage » ou « soc de camoflague ». Si l’équipe de mission avait comme objectif d’appariement de recenser ces autres variations de noms d’entreprise, elle devra réduire le pourcentage du seuil et documenter la justification du choix de ce seuil.

Q2. Si l’équipe de mission consigne des équations, des définitions d’importation, des macros, des macros Visual Script ou des modèles Visual d’IDEA dans le dossier d’audit (p. ex. en vue de l’audit d’un exercice postérieur), où et comment ces éléments peuvent-ils être incorporés dans le dossier d’audit?

R2. Tout fichier justificatif, y compris les équations d’IDEA (.EQX), les définitions d’importation d’IDEA (.jpm, .rdf et .xrdf), les macros d’IDEA (.iss), les macros Visual Script d’IDEA (.vscript) et les modèles Visual d’IDEA (.idash), peut être importé dans le dossier d’audit. L’auditeur ne doit pas joindre de fichiers ni de documents aux feuilles de travail, car cela peut corrompre les feuilles de travail. Il faut savoir que lorsque ces fichiers sont intégrés au dossier d’audit, l’utilisateur doit avoir installé le logiciel correspondant pour ouvrir les fichiers.
Seules les versions définitives de ces fichiers justificatifs doivent être ajoutées dans le dossier d’audit (car il est impossible de modifier les fichiers consignés dans le dossier d’audit).