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, accéder à la base de données, 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, et qui les examine.
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. Sur un grand nombre de missions, le risque lié aux contrôles informatiques généraux est identifié comme un risque significatif dès la phase de planification.

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 ET enregistrer le paiement 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 et la payer. 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, supprimée ou créée sans justification, l'ERP ne dira jamais qui a fait quoi, ni quand.
Note de documentation : Absence de logs de traçabilité. Aucune 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, sans documentation, sans 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, inspection physique des stocks, réconciliations externes).

Ce que les auditeurs et les examinateurs comprennent mal

Confusion entre contrôles informatiques généraux et contrôles d'application : Les auditeurs documentent souvent 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é : Beaucoup de PME utilisent des identifiants partagés, ce qui est classé comme une défaillance majeure des contrôles informatiques généraux dans les rapports d'inspection du FRC et de l'AFM. Mais les auditeurs la tolèrent souvent en disant : « C'est une petite entité. » ISA 315.18 ne distingue pas par taille.
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, d'enregistrer et de conserver la responsabilité d'une transaction.
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.