Contrôles informatiques généraux

Fonctionnement

Les contrôles informatiques généraux forment l'ossature sur laquelle reposent tous les contrôles d'application. Si ce niveau échoue, aucun contrôle d'application ne peut être fiable, même s'il est techniquement bien conçu. ISA 315.18 exige que vous compreniez les contrôles informatiques généraux pertinents pour l'audit, et cela signifie bien au-delà du simple inventaire des mots de passe.

Sur une mission d'audit, vous identifiez les contrôles informatiques généraux en posant une question simple : qui peut apporter des modifications non détectées à l'application ou à ses données ? Cela couvre quatre catégories. L'accès physique et logique : qui peut se connecter au serveur et accéder à la base de données, qui peut modifier le code source. Les changements de configuration : comment les modifications au système sont-elles autorisées, testées, documentées et déployées. Les sauvegardes et la récupération : les données peuvent-elles être restaurées si un incident les compromet. Les logs et la surveillance : quelles activités sont enregistrées, pendant combien de temps, qui les examine, et si une alerte est déclenchée en cas d'anomalie.

Un contrôle informatique général bien conçu empêche une personne seule d'apporter une modification significative sans laisser de traces. ISA 315.20 indique que l'absence de ce type de contrôle augmente considérablement le risque d'anomalies non détectées. Chez nos clients, le risque lié aux contrôles informatiques généraux est identifié comme un risque significatif dès la phase de planification. Quand l'environnement IT du client est une usine à gaz (applications empilées, droits d'accès jamais revus, aucun log centralisé, pas de procédure de changement formalisée), ce risque devient le premier point de discussion avec l'associé signataire.

Exemple pratique : Durand Textile SARL

Client : Durand Textile SARL, PME française, chiffre d'affaires 8,4 M EUR, logiciel de gestion ERP interne développé il y a six ans, trois utilisateurs avec accès base de données.

Étape 1 : Identifier le risque lié à l'accès L'ERP de Durand gère le cycle ventes-recettes et le cycle achats-décaissements. Les trois comptables ont accès direct à la base de données pour corriger les erreurs de saisie. Aucun rôle d'utilisateur n'est défini ; l'accès est un identifiant partagé sur Post-it collé à côté de l'écran. Note de documentation : Revue des droits d'accès aux systèmes critiques. Aucune liste formelle de rôles d'utilisateur. Accès par identifiant partagé observé.

Étape 2 : Évaluer la séparation des fonctions Vous posez la question : une personne peut-elle autoriser une facture, la comptabiliser, enregistrer le paiement ET modifier le solde du compte fournisseur sans intervention d'une autre ? Oui. Les trois comptables ont le même accès à l'ERP. Aucun workflow d'approbation n'est en place. Une facture peut passer de zéro à payée en dix minutes sans signature électronique. Note de documentation : Absence de séparation des fonctions dans le cycle achats. Un utilisateur peut créer une facture fournisseur, l'approuver, la payer et modifier le lettrage. Aucun système de validation multi-niveaux.

Étape 3 : Documenter les logs Vous demandez où sont stockés les logs des accès à la base de données. Il n'y en a pas. Les modifications apportées à la base de données ne sont pas enregistrées dans un fichier d'audit. Si une facture est modifiée ou supprimée sans justification, l'ERP ne dira jamais qui a fait quoi, ni quand. Note de documentation : Absence de logs de traçabilité. Aucun enregistrement des modifications de données en base. Aucun historique d'accès. Les modifications de soldes de compte ne peuvent pas être auditées.

Étape 4 : Évaluer les changements de configuration Vous demandez comment une modification du code de l'ERP ou de sa configuration est mise en place. Le propriétaire (un retraité) modifie parfois le code sur le serveur de production directement, sans test préalable et sans documentation ni approbation écrite. Note de documentation : Aucune politique de gestion des changements. Les modifications de code sont faites directement en production. Aucune séparation entre les environnements de développement et de production.

Conclusion : Les contrôles informatiques généraux de Durand sont inexistants. L'accès n'est pas contrôlé, la séparation des fonctions n'existe pas, les logs n'existent pas, et les changements de configuration ne sont pas gérés. ISA 315.20 indique que cette situation augmente le risque d'erreurs non détectées à un niveau inacceptable. Sur une mission réelle, cela déclencherait une restriction significative du scope ou une augmentation massive des procédures de validation externe (demandes de confirmation bancaire et inspection physique des stocks, réconciliations externes et circularisations fournisseurs).

Ce que les auditeurs et les examinateurs comprennent mal

- Confusion entre contrôles informatiques généraux et contrôles d'application : Dans les dossiers que nous revoyons, les auditeurs documentent un contrôle d'application (ex. : « un champ obligatoire sur le devis ») et considèrent que le risque informatique est couvert. En réalité, si la personne qui saisit peut modifier les données enregistrées sans log, le contrôle d'application s'écroule. ISA 315.19 distingue explicitement ces deux niveaux.

- Sous-estimation du risque d'accès partagé : Chez nos clients TPE/PME, les identifiants partagés restent la norme. Le H2A et la CNCC classent cette situation comme une défaillance majeure des contrôles informatiques généraux dans leurs rapports d'inspection. Les auditeurs la tolèrent pourtant en disant : « C'est une petite entité. » ISA 315.18 ne distingue pas par taille. C'est agaçant de voir des équipes évaluer ce risque au doigt mouillé alors que la norme est sans ambiguïté sur le sujet.

- Logs non auditables en raison du volume ou de la rétention : L'entité maintient des logs, mais ils ne contiennent que 30 jours d'historique, tournent tous les jours, ne sont pas archivés, et ne peuvent pas être filtrés par utilisateur ou par compte. ISA 330.6 exige que vous testiez l'existence de contrôles. Si les logs ne sont pas auditables, le contrôle n'existe pas effectivement.

Outils et ressources

Utilisez la Matrice de contrôles informatiques généraux pour documenter l'état des quatre domaines (accès, changements, sauvegardes, logs) sur votre engagement. Cet outil vous permet de classer rapidement le risque en fonction de la complétude de chaque catégorie et de générer les papiers de travail pour l'associé.

Termes connexes

- Contrôles d'application : Les contrôles automatisés ou manuels spécifiques à un processus métier (validation de facture, calcul de paie) qui supposent que les contrôles informatiques généraux fonctionnent.

- Environnement de contrôle : Le contexte organisationnel plus large dans lequel la direction établit ses responsabilités de contrôle interne.

- ISA 315 révisée (2019) : La norme qui redéfinit l'identification des risques significatifs et la compréhension des contrôles liés à l'informatique.

- Séparation des fonctions : Le contrôle qui empêche une personne seule d'autoriser et d'enregistrer une transaction tout en conservant la responsabilité de sa garde.

- Tests de contrôle : Les procédures que vous appliquez pour évaluer l'efficacité opérationnelle d'un contrôle informatique général.

- Risque de fraude liée à l'informatique : Le risque spécifique qu'un utilisateur malveillant ou un administrateur système contourne les contrôles informatiques généraux pour modifier les données financières sans détection.

---