Les défis et solutions en audit financier sont exacerbés par l’évolution rapide des technologies de l’information. Cette recherche met en lumière comment ces innovations transforment les pratiques d’audit en Tunisie, offrant des réponses essentielles aux nouveaux risques technologiques.
Section 3 :
L’examen des contrôles d’application
La cartographie est établie durant la phase de planification. Elle décrit la relation entre les activités de chaque cycle et les comptes correspondants.
Cartographie
La vue d’ensemble présente les activités de chaque cycle, les transactions clefs ainsi que les bases de données.
Documentation
Description détaillée
Vue d’ensemble
La description détaillée présente les transactions et les contrôles au niveau de chaque activité.
Après la documentation des systèmes, un ensemble de contrôles clefs peut être sélectionné. Ces contrôles, convenablement documentés, devraient être testés.
Tester les contrôles clefs
Sélection des contrôles clefs
L’audit informatique n’est pas censé examiner tous les contrôles d’application. Son champ d’action est déterminé en commun accord avec l’équipe d’audit financier. Toutefois, dans la majorité des cas, l’équipe d’audit informatique sera chargée de l’audit des contrôles d’applications programmés et des suivis manuels rattachés.
L’examen des contrôles d’application se divise en trois étapes détaillées dans le schéma qui suit :
- La documentation des transactions et des process
- L’identification des contrôles clefs d’application
- Les tests portant sur les contrôles d’application clefs
Sous section 1 :
La documentation des transactions et des process
La documentation des transactions et des process constitue une étape préalable pour l’examen des contrôles d’application (et aussi des contrôles de direction). Elle doit permettre aux lecteurs de comprendre de manière claire et sans ambiguïté le processus revu et aux auditeurs d’identifier les contrôles clés ainsi que les zones de risques.
Pour réaliser cette documentation, et en plus des interviews avec les différents responsables de l’entreprise, l’auditeur peut examiner les dossiers de correspondance, les statistiques clefs, l’organigramme, les rapports d’audit interne, les rapports de consultant, les manuels de procédures et les anciens rapports d’audit externes y compris les anciens commentaires de la direction.
La documentation doit indiquer :
- Les entrées, leur forme (papier, écran, support magnétique…), leur origine (utilisateur ou autre application en amont), les modes d’autorisation, les contrôles de validité faits par les utilisateurs et les contrôles automatisés ;
- Les fichiers : il s’agit des fichiers qui sont utilisés ou mis à jour par l’application. En général, il n’est pas tenu compte des fichiers intermédiaires mais seulement des fichiers principaux. Pour chacun, il y a lieu de connaître son contenu, son utilisation et les contrôles qui assurent son intégrité.
- Les traitements : il s’agit de recenser les principales fonctions et leur fréquence et d’identifier les procédures de contrôles informatisées et manuels
- Les sorties, leur forme (états, fichiers magnétiques…), leur contenu, les contrôles exercés notamment sur le chemin de révision.
La nature et l’étendue de la documentation propre à chaque cas dépendent de nombreux facteurs parmi lesquels :
- Le degré de fiabilité que l’auditeur pense accorder aux contrôles et aux fonctions de traitement informatisées
- Le risque propre à chaque composant et son importance relative
- L’existence ou non de documentations préparées par l’entreprise sur les systèmes
- La complexité des systèmes : s’ils sont particulièrement compliqués, une documentation détaillée, comprenant également des organigrammes, sera de circonstance
- Le degré d’utilisation et de sophistication du système informatique
- La nature de l’activité : dans certains industries spécialisées, les contrôles utilisés sont souvent spécifiques et les questionnaires généraux peuvent être mal adaptés.
Par ailleurs, la documentation peut revêtir de nombreuses formes dont les plus communes sont :
- Les organigrammes ou diagrammes de flux (Flowchart)
- Des descriptions sous forme narrative
- Des questionnaires spécialement adaptés
Aujourd’hui, la technique de documentation la plus utilisée est le « flowcharting » du fait que les auditeurs la trouvent de plus en plus efficace de part sa simplicité. Plusieurs logiciels informatiques se sont développés aidant non seulement à l’élaboration de flowcharts mais aussi à l’identification des contrôles clés potentiels.
Le flowcharting est une technique de description de procédures qui se base essentiellement sur des formes géométriques généralement standardisées (accompagnés le plus souvent par des notes écrites).
Il existe plusieurs techniques de flowcharting, dont les principales sont :
- La technique horizontale : Dans ce cas, le flux des transactions est présenté de gauche à droite sur chaque page.
- La technique horizontale par organisation : Le flux des informations est, dans ce cas, présenté de gauche à droite par sous unités organisationnelles. Pour chaque sous unité organisationnelle, les procédures ou les opérations s’y rattachant sont présentées verticalement. Le flowchart serait présenté du côté haut gauche au côté bas droit de la page.
- La technique de présentation verticale : Dans ce cas, le flux des transactions est présenté de haut en bas selon une simple ligne, présentant les opérations séquentielles affectant chaque transaction avec les documents et les fichiers nécessaires à chaque opération.
C’est cette dernière technique qui semble la plus utilisée par les auditeurs. En outre, et lors de la préparation des flowcharts, il conviendrait de suivre les règles suivantes :
- Présenter le flux principal des activités et des contrôles sur une ligne verticale au milieu du diagramme
- Du côté gauche du flowchart, il convient d’ajouter les principales entrées (input) : documents, fichiers informatiques, etc.
- Du côté droit du flowchart, il convient d’ajouter les principales sorties (output) : documents, fichiers informatiques, etc.
- La séquence des activités devrait courir du haut en bas
- Chacun des flowcharts devrait être présenté sur une seule page. Si la présentation excède la page, alors il serait pertinent de regrouper les activités en processus plus élevés, pour pouvoir les détailler par la suite.
En outre, le flowchart doit pouvoir être lu à plusieurs niveaux :
- Vue d’ensemble : Elle permet d’avoir une vue globale de chaque cycle montrant les activités principales, les transactions les plus importantes, les bases de données utilisées et mises à jour et les principales entrées et sorties des différentes activités.
La vue d’ensemble devrait contenir les éléments suivants :
- Tous les documents saisis dans le système
- Les principales étapes de traitement et les principales activités
- Les documents et les fichiers informatiques utilisés par plus que d’un process
- Les comptes mouvementés suite à l’enregistrement des opérations
- Eventuellement, la taille et le volume des transactions ainsi que les soldes des comptes correspondants (Cette information est utile pour l’évaluation de l’impact des faiblesses de contrôle interne soulevées)
- Un sommaire des rapports produits par le système informatique. Ces rapports sont de deux types : les rapports de routine68 et les rapports d’exception69.
- Vue détaillée : Une fois le flowchart décrivant la vue d’ensemble a été achevé, la prochaine étape consisterait à fournir de plus amples détails et ce, en préparant des flowcharts pour chacune des activités principales.
68 Les rapports de routine sont afférents aux transactions normales
69 Les rapports d’exception (Audit log) concernent les transactions ou les opérations ne correspondant pas à une opération ou à une situation courante (exemple : stock négatif, marge inhabituelle etc.)
Exemple de flowcharts70 du cycle revenus/clients d’une entreprise hôtelière :
Création code
Prestations
Prévisions de
6
Clients
10
Vue d’ensemble :
Vue détaillée (prévisions de réservation) :
Profil utilisateur
1
d’allotement des Tours Opérateurs.
Réservations
2
Avis de crédit bancaire
Recettes journalières des points de ventes
Crédit : clients en cours
Débit : Clients
Crédit : Revenus
Revenus front office
Crédit : TVA collectée
Débit : Clients en cours
15
Tarifs extras
Rapport d’exception (annulation et modification)
14
Bon voucher
13
revenus front office
Chambres
12
Liste des arrivées prévus
Codes arrangements
8
Liste des arrivées prévues
RRéésseervravtaitoionn
5
Codes arrangements
Contrats
d’allotement des Tours Opérateurs
Black & cash list
Contrats
Réservations Tours Opérateurs
Réservation
Réservations T.O.
9
T.O.
Saisie des prévisions de réservations | ||
x 17 | ||
Négociati commerci | ons ales | |
x 3 | ||
Contrôle automatique de la validité des réservations | ||
CA c 18 | ||
arrangem | ent | |
x 4 | ||
Validation des prévisions des réservations | ||
x 19 | ||
réservati | on | |
x 7 | ||
Edition de des prévi arrivées | la liste sions des | |
x 20 | ||
rendues | ||
x 11 | ||
Comptabilisation x | ||
Réglement x |
Crédit : clients | |
Débit : Liquidités & équivalents de liquidités | |
70 Ces flowcharts ont été réalisés à l’aide d’un software d’aide à la documentation propre au cabinet international PricewaterhouseCoopers.
La signification de chaque symbole utilisé est :
Explications | Symboles |
Activités : (Les activités peuvent être manuelles, automatisées ou mixtes). | |
Contrôle | |
Fichier électronique | |
Documents Papier | |
Rapport de contrôle | |
Comptes comptables | |
Eléments de données |
N.B : Les chiffres à l’intérieur des symboles font référence à des annotations explicatives et à des informations utiles au lecteur (volume des opérations, leurs montants, etc.).
Généralement, après la préparation ou la mise à jour de la documentation des systèmes, l’auditeur doit confirmer sa compréhension des procédures à travers la réalisation de tests de cheminement. Cependant, il peut être plus efficace de réaliser ces tests et de préparer la documentation correspondante en même temps.
Les tests de cheminement doivent porter aussi bien sur les procédures manuelles que sur les procédures automatisées. Dans la pratique, concernant les procédures automatisées, les problèmes suivants peuvent être rencontrés :
- Les transactions sont parfois groupées en batchs avant leur traitement par l’ordinateur. Habituellement, un résumé des procédures appliquées au groupe est rapporté sans que des évidences du traitement de chaque transaction individuelle ne soient documentées.
- Les procédures programmées peuvent consister en un ou plusieurs programmes complexes et englober une multitude de fichiers informatiques.
Parmi les types de tests de cheminement concernant les procédures automatisées, nous citons :
- La répétition des procédures automatisées : Cette méthode n’est possible que dans les systèmes informatiques simples où toutes les informations nécessaires pour la répétition du traitement sont disponibles.
- La revue de la documentation des programmes : Si la documentation est suffisante et correspond à la version de l’application utilisée, l’auditeur peut la revoir afin de confirmer sa compréhension des procédures automatisées
- La revue limitée du code source : Ceci peut être appliquée si la documentation existante ne décrit pas convenablement les procédures automatisées, si elle est incomplète ou non à jour et si elle ne peut être utilisée dans la confirmation de la compréhension des procédures.
Questions Fréquemment Posées
Quels sont les étapes de l’examen des contrôles d’application en audit financier?
L’examen des contrôles d’application se divise en trois étapes : la documentation des transactions et des process, l’identification des contrôles clefs d’application, et les tests portant sur les contrôles d’application clefs.
Comment se déroule la documentation des transactions et des process en audit?
La documentation des transactions et des process doit permettre aux lecteurs de comprendre le processus revu et aux auditeurs d’identifier les contrôles clés ainsi que les zones de risques. Elle inclut des interviews, l’examen de dossiers, et doit indiquer les entrées, fichiers, traitements et sorties.
Quels facteurs influencent la nature et l’étendue de la documentation en audit?
La nature et l’étendue de la documentation dépendent de plusieurs facteurs, tels que le degré de fiabilité accordé aux contrôles, le risque propre à chaque composant, l’existence de documentations préparées par l’entreprise, la complexité des systèmes, et la nature de l’activité.