La méthodologie d’audit financier révèle que l’intégration des technologies de l’information transforme radicalement les pratiques d’audit en Tunisie. Cette recherche met en lumière des enjeux cruciaux pour les auditeurs face aux nouveaux risques technologiques, avec des implications significatives pour la fiabilité des états financiers.
Section 4 :
La phase de finalisation
Cette phase représente l’analyse des résultats des tests sur les contrôles d’application et des tests sur les contrôles généraux informatiques clefs.
Si des faiblesses ont été notées, l’auditeur doit considérer :
- Les types d’erreurs qui pourraient se produire dues à chacune des faiblesses
- Si l’erreur pourrait avoir un effet significatif sur la fiabilité des états financiers
- Si la faiblesse est en rapport avec les contrôles généraux informatiques, s’il existe des contrôles d’application compensatoires
Par ailleurs, s’il est établit que les contrôles et les fonctions de traitement informatisées sont inefficaces à un moment donné, il est probable qu’un certain nombre de transactions seraient affectées.
En outre, concernant les contrôles clefs manuels (y compris ceux associés aux contrôles d’application automatisés), l’auditeur ne doit pas s’attendre à ce qu’ils soient toujours efficaces. L’auditeur doit évaluer les déviations détectées au cours des tests de conformité et déterminer si le taux effectif de déviation et inférieur au taux de déviation admissible déterminé durant la phase de planification.
Suite à l’analyse des résultats, l’auditeur doit considérer si les procédures d’audit planifiées donneront une assurance suffisante pour déterminer si la faiblesse dégagée pourrait résulter, ou a résulté, en une erreur significative dans les états financiers. Dans certains cas, il peut juger nécessaire de concevoir une procédure d’audit spécifique. Si par suite de ce processus, l’auditeur détermine que les objectifs de contrôle demeurent assurés, il doit considérer d’informer l’entreprise de la faiblesse concernée.
Dans ce qui suit, nous présentons des exemples de faiblesses pouvant être relevées ainsi que les risques correspondants :
1/ Organisation :
Faiblesses | Risques |
Absence de séparation des tâches entre les départements des études informatiques et de l’exploitation. | Accès direct des développeurs à l’environnement de production et modification des données avec des outils de développement |
Absence de responsable de la sécurité informatique (physique, logique, plan de secours) | Stratégie de sécurité de l’entreprise non adaptée aux besoins de la société et entraînant des failles importantes dans le dispositif de sécurité |
2/ Développement et maintenance des systèmes :
Faiblesses | Risques |
Absence de méthodologie de conception ou d’acquisition de systèmes | Prise en compte incorrecte des besoins des utilisateurs, lenteur des développements, qualité insuffisante de la documentation rendant difficile la pérennité des systèmes |
Absence de procédures de demande de changement | Des changements de programmes non autorisés peuvent causer des erreurs au niveau des états financiers |
Absence de méthodologie de tests | Tests insuffisants entraînant des anomalies en production. |
Test dans l’environnement de production | Des données de test peuvent être prises en compte dans les états financiers |
3/ Exploitation :
Faiblesses | Risques |
Absence de revue des travaux d’exploitation | Anomalies d’exploitation non détectées et donc non corrigées et pouvant porter atteinte à l’intégrité des données de l’entreprise |
Absence de Plan de Continuité d’Exploitation | Arrêt des activités critiques de l’entreprise en cas de sinistre informatique important |
Des procédures de sauvegarde et de restauration inadéquates | Risque de pertes de données et incapacité de restaurer les systèmes et/ou leurs données. Le coût de restaurer les données peut être élevé. |
4/ La sécurité physique et logique :
Faiblesses | Risques |
Sécurité insuffisante : Absence de contrôles logiques et physiques sur les accès (Exemple : absence de Firewall contrôlant l’accès des tierces personnes via Internet) | Des mises à jour non autorisées des bases de données, une mauvaise utilisation ou une destruction des données, la perte de la confidentialité, etc. Intrusion de personnes étrangères (surtout dans le cas d’EDI, d’E-commerce, E-business, etc.) |
Absence de revue régulière des profils utilisateurs et de leurs habilitations | Utilisation de profils « dormants » pour entreprendre des opérations frauduleuses (saisie de données, diffusion d’informations confidentielles, etc.) |
Documentation inadéquate | Dépendance sur une personne clef. Les changements du système peuvent être difficiles, chers ou impossibles. |
5/ Interfaces :
Faiblesses | Risques |
Sécurité absente ou insuffisante des interfaces | Altération des données |
Vérification insuffisante des données reçues par rapport aux données envoyées (exemple : entre le site Web et le back-office) | Les données financières peuvent être perdues ou altérées lors du transfert. |
6/ Séparation des tâches :
Faiblesses | Risques |
Le personnel informatique peut avoir accès à des transactions utilisateurs | Les utilisateurs et le personnel de support informatique peuvent créer des fournisseurs et des clients, créer des bons de commande, recevoir des biens, entrer des données en comptabilité générale, effectuer des paiements, etc. (risque de fraude, de divulgation d’informations confidentielles, etc.…) De telles possibilités affectent la crédibilité des données financières. |
Des utilisateurs peuvent avoir accès à des fonctions élevées d’administration du système | |
Les utilisateurs et le personnel informatique ont des tâches incompatibles avec leurs fonctions. | |
Des droits étendus ou inappropriés peuvent être donnés à des personnes non autorisées Un manque de standard dans la dénomination des profils | Certains profils peuvent être utilisés pour valider des transactions non autorisées. Certains profils peuvent permettre d’effectuer la quasi-intégralité des fonctions, sans nécessairement respecter la séparation des tâches. |
7/ Contrôles d’application :
Faiblesses | Risques |
Les personnes chargées de la validation peuvent avoir accès à la maintenance des tables. | Les employés ayant les autorisations pour maintenir les tables peuvent outrepasser les limites d’approbation. |
Insuffisance des contrôles programmés lors de la saisie de données | Erreurs sur les montants saisis, enregistrement dans une mauvaise période, imputation incorrecte |
Absence de procédures automatiques de réconciliation entre une facture fournisseur et un bon de commande | Enregistrement de facture non réelle, double enregistrement de facture |
Le système est configuré pour n’afficher qu’un message d’alerte quand un paiement est saisi deux fois dans le système. | Les factures peuvent être payées plusieurs fois si le contrôle n’est pas bloquant. |
Absence de procédure de revue du listing des règlements | Enregistrement d’opérations de règlements non autorisées |
Les factures, chèques et journaux peuvent être entrées dans le système pour toutes les périodes ouvertes. | Les écritures sont saisies sur les mauvaises périodes comptables générant des problèmes de cut-off. |
Ces faiblesses et leurs impacts sur la stratégie d’audit font l’objet d’un compte rendu à l’attention de l’équipe d’audit financier. En outre, un rapport de contrôle interne peut aussi être adressé à l’attention de la Direction Générale.
Sous section 1 :
Le compte rendu à l’attention de l’équipe d’audit
Après l’achèvement de ses travaux, l’auditeur informatique doit élaborer un compte rendu à l’attention de l’équipe d’audit financier. Ce compte rendu doit indiquer clairement :
- Les objectifs et les limites de l’intervention :
Le compte rendu rappelle les objectifs et les limites de la mission d’audit informatique engagée dans le cadre de l’audit financier ainsi que les conditions d’exécution.
- Les travaux effectués :
Il s’agit de décrire les étapes, l’étendue (système d’information, applications, etc.), les cycles et les comptes comptables couverts par l’audit informatique. Il y a lieu de rappeler que les cycles et les comptes comptables à auditer sont déterminés lors de la phase de la collecte d’informations sur les systèmes et l’environnement informatique en commun accord avec l’équipe d’audit financier.
En outre, l’auditeur doit indiquer, éventuellement, les limitations de l’étendue de ses travaux imposées par l’entreprise auditée.
- Les principaux points et les conclusions :
Il s’agit de décrire les points susceptibles de modifier la stratégie d’audit, les faiblesses de contrôle, le niveau de risque, et les points à reporter à la Direction de l’entreprise. Il convient de signaler que l’obtention des commentaires de la direction sur les points dégagés peut être utile à l’équipe de l’audit financier.
Par ailleurs, sur la base des travaux entrepris, l’auditeur doit évaluer les assertions sous-jacentes à chaque cycle et à chaque compte comptable.
L’auditeur doit aussi indiquer, à ce niveau, les cas relevés de non-respect par l’entreprise des dispositions informatiques prévues par la réglementation comptable, juridique et fiscale. Ceci est d’autant plus important en cas d’une mission de commissariat aux comptes où l’obligation de révélation des faits délictueux est entière.
- L’impact sur l’audit :
Sur la base des faiblesses relevées et des risques induits, l’auditeur informatique recommande, à l’équipe d’audit financier, les tests de détails nécessaires à entreprendre, lors de l’audit final des comptes, pour valider les assertions non couvertes.
Sous section 2 :
Le rapport sur les faiblesses de contrôle interne
L’auditeur informatique peut présenter à la Direction Générale de l’entreprise auditée un rapport de contrôle interne indiquant les insuffisances des procédures et des contrôles relevées au cours de l’audit. Ce rapport peut, aussi, indiquer les grandes lignes des moyens à mettre en œuvre avec l’ordre de priorité selon lequel chaque élément devrait être pris en considération et ce, pour ramener le risque à un niveau acceptable compte tenu des contraintes spécifiques à l’entreprise.
La structure du rapport de contrôle interne est critique pour une communication effective des résultats de l’audit. A titre indicatif, le rapport doit inclure les éléments suivants :
- L’étendue des travaux d’audit
- Les domaines ou les comptes examinés
- Une description sommaire de la méthodologie suivie
- L’opinion sur les systèmes objets de la revue
- Un sommaire des faits constatés
- La présentation détaillée des faits constatés
- Une présentation des recommandations, des actions à mener et l’ordre de priorité correspondant à chacune des recommandations et actions
Par ailleurs, l’auditeur informatique doit préciser que les situations décrites dans son rapport sont celles observées dans le cadre des travaux d’audit financier et, par conséquent, les commentaires ne comportent pas nécessairement une description de toutes les situations qui mériteraient une amélioration et qui auraient été mises en évidence par une étude plus spécifique et détaillée.
Sous section 3 :
Le dossier de synthèse
Le dossier de synthèse afférent à l’intervention de l’audit informatique dans le cadre de l’audit financier peut contenir, essentiellement, les éléments suivants :
- La synthèse de fin de mission
- Les rapports et les comptes rendus émis
- Le plan stratégique et le programme de travail
- Les procès verbaux des réunions internes de l’équipe d’audit informatique
- Les procès verbaux des réunions avec l’équipe d’audit financier
- Les procès verbaux des réunions avec les différents responsables de l’entreprise auditée
- L’équipe intervenante, le budget, les temps consommés
- La cartographie
- La documentation des systèmes
Conclusion :
L’évolution croissante des technologies de l’information et de la communication élargit de plus en plus le champ et les domaines d’intervention de l’audit informatique en support à l’audit financier.
Par ailleurs, la démarche présentée, tout au long de ce chapitre, peut être appliquée dans le cadre d’une mission d’audit informatique indépendante non rattachée à une mission d’audit financier ou dans le cadre d’une mission d’audit interne informatique. Dans ces cas, le champ d’action est généralement plus élargi et la responsabilité et l’autorité de la mission doivent être définies de façon appropriée dans une lettre de mission ou une charte d’audit.
Aussi, est-il nécessaire de rappeler que l’auditeur informatique est tenu de respecter les règles d’éthique d’indépendance, d’intégrité, d’objectivité, de compétence professionnelle, de confidentialité, de professionnalisme et de respect des normes techniques et professionnelles.
L’auditeur informatique doit être indépendant de l’entité auditée en attitude et en apparence. Il doit aussi être suffisamment indépendant du domaine audité pour permettre une réalisation objective de l’audit.
Questions Fréquemment Posées
Quelles sont les faiblesses liées à l’organisation dans l’audit financier?
Les faiblesses liées à l’organisation incluent l’absence de séparation des tâches entre les départements des études informatiques et de l’exploitation, ainsi qu’une absence de responsable de la sécurité informatique.
Comment les faiblesses dans le développement des systèmes peuvent-elles affecter l’audit financier?
Les faiblesses dans le développement des systèmes, comme l’absence de méthodologie de tests, peuvent entraîner des anomalies en production qui affectent les états financiers.
Quels risques sont associés à l’absence de plan de continuité d’exploitation?
L’absence de plan de continuité d’exploitation peut entraîner l’arrêt des activités critiques de l’entreprise en cas de sinistre informatique important.
Pourquoi est-il important d’évaluer les contrôles généraux informatiques dans l’audit financier?
Il est important d’évaluer les contrôles généraux informatiques pour déterminer si des faiblesses pourraient avoir un effet significatif sur la fiabilité des états financiers.