ITGC, ITAC et IPE : ce que contrôle le commissaire aux comptes dans le système d’information

ITGC, ITAC et IPE : ce que contrôle le commissaire aux comptes dans le système d’information

L’audit du système d’information par le commissaire aux comptes n’est pas un audit informatique séparé de la mission légale. Il sert à comprendre dans quelle mesure les applications, les accès, les interfaces et les traitements automatisés influencent la fiabilité des comptes. Dès qu’un ERP, un outil SaaS ou une chaîne de facturation produit des écritures comptables, le SI entre dans la preuve d’audit.

Pour une direction financière, une DSI ou une équipe d’audit, l’enjeu est simple : identifier les contrôles qui sécurisent l’information financière, repérer les faiblesses susceptibles de créer des anomalies significatives et ajuster les travaux de certification. La démarche s’inscrit dans l’esprit des NEP 315 et NEP 330, centrées sur l’identification des risques et les réponses d’audit à apporter.

Pourquoi le système d’information entre dans la mission du commissaire aux comptes

La certification des comptes repose sur des données produites, transformées et stockées par le système d’information de l’entité. Ventes, achats, paie, immobilisations, stocks, trésorerie : la plupart des cycles comptables dépendent aujourd’hui de traitements automatisés. Si ces traitements sont mal paramétrés, insuffisamment contrôlés ou modifiables sans traçabilité, le risque ne concerne pas seulement la DSI, il touche directement les états financiers.

Quiz : Audit du Système d'Information

Un sujet de fiabilité comptable avant d’être un sujet technique

Le commissaire aux comptes ne cherche pas à certifier la performance du SI ni à délivrer un label de cybersécurité. Il vérifie si l’environnement informatique permet de produire une information financière fiable, exhaustive, exacte et traçable. Une faiblesse sur la gestion des habilitations, par exemple, peut permettre à un utilisateur de créer un fournisseur, saisir une facture et valider un paiement sans séparation des fonctions. Le sujet informatique devient alors un risque de fraude ou d’erreur comptable.

Une approche fondée sur les risques d’anomalies significatives

La NEP 315 conduit l’auditeur à prendre connaissance de l’entité, de son environnement et de son contrôle interne pour identifier les risques d’anomalies significatives. Lorsque les processus comptables sont fortement automatisés, cette prise de connaissance inclut les applications clés, les interfaces, les traitements récurrents, les contrôles embarqués et les informations produites par l’entité. La NEP 330 guide ensuite les réponses à ces risques : tests de contrôles, procédures substantives, analyse de données ou travaux complémentaires.

Ce que couvre réellement un audit SI dans un cadre légal

L’audit système d'information commissaire aux comptes se concentre sur les composants du SI qui ont un impact potentiel sur les comptes. Le périmètre dépend donc de la cartographie des flux financiers : applications métier, ERP, outils de consolidation, logiciels de paie, interfaces bancaires, plateformes de facturation électronique, fichiers de calcul ou états utilisés comme pièces justificatives.

Audit système d'information commissaire aux comptes : schéma des contrôles ITGC, ITAC et IPE
Audit système d'information commissaire aux comptes : schéma des contrôles ITGC, ITAC et IPE

Audit légal, audit contractuel et audit de cybersécurité : ne pas confondre

Type d’audit Objectif principal Exemples de travaux
Audit légal du SI Apprécier l’impact du SI sur la fiabilité des comptes ITGC, ITAC, IPE, interfaces, droits utilisateurs, traçabilité
Audit contractuel Répondre à un besoin spécifique de l’entreprise Revue d’un ERP, diagnostic de gouvernance IT, contrôle d’un projet de migration
Audit de cybersécurité Évaluer l’exposition aux menaces et la robustesse de la sécurité Tests d’intrusion, analyse de vulnérabilités, conformité ISO 27001, RGPD ou NIS2

Ces périmètres peuvent se recouper, mais leur finalité diffère. Un incident de cybersécurité intéresse le commissaire aux comptes s’il peut entraîner une perte de données, une altération des écritures, une indisponibilité qui affecte la clôture ou une remise en cause de la continuité d’exploitation.

Les livrables utiles pour l’auditeur et pour l’entreprise

Les travaux peuvent donner lieu à des synthèses de risques, des matrices de contrôles, des constats d’anomalies, des recommandations et un plan d’action. Pour l’entreprise, l’intérêt dépasse la seule certification : l’audit met souvent en évidence des fragilités opérationnelles concrètes, comme des comptes génériques non maîtrisés, des sauvegardes non testées, des changements applicatifs insuffisamment documentés ou des interfaces sans rapprochement.

Les trois familles de contrôles à comprendre : ITGC, ITAC et IPE

La terminologie peut sembler technique, mais elle répond à une logique simple : avant de se fier à une donnée ou à un contrôle automatisé, l’auditeur vérifie que l’environnement informatique qui les produit est suffisamment maîtrisé. Les trois familles de contrôles se complètent et permettent de relier le SI à la qualité des comptes.

NEP 315 : connaître l’entité et évaluer les risques d’audit | Cette norme officielle explique comment le commissaire aux comptes analyse l’entité, son environnement et les risques d’anomalies significatives dans les comptes.

ITGC : les contrôles généraux informatiques

Les ITGC, ou contrôles généraux informatiques, concernent le socle du SI. Ils couvrent notamment la gestion des accès utilisateurs, les comptes à privilèges, la séparation des fonctions, la gestion des changements, l’exploitation informatique, les sauvegardes, le plan de continuité d’activité et la gestion des incidents. Si ces contrôles sont faibles, la confiance accordée aux applications peut être réduite, même si les traitements semblent corrects en apparence.

Un SI ressemble à une succession de portes verrouillées : application, base de données, interface, répertoire d’export, outil de reporting. L’erreur fréquente consiste à regarder seulement la porte visible, par exemple l’écran de validation d’une facture. Or le verrou décisif peut se trouver plus loin : un compte administrateur partagé, un fichier d’import modifiable avant intégration, une règle de workflow contournable ou un journal de connexions non conservé. Pour l’auditeur, remonter cette chaîne permet de distinguer un contrôle réellement protecteur d’un simple affichage rassurant.

ITAC : les contrôles applicatifs

Les ITAC, ou contrôles applicatifs, sont intégrés aux applications métier. Ils peuvent être automatisés ou semi-automatisés : blocage d’une facture sans bon de commande, contrôle de cohérence entre commande, livraison et facturation, seuil d’approbation, numérotation séquentielle, rapprochement bancaire, calcul automatique d’une provision ou contrôle d’exhaustivité d’une interface. Leur efficacité dépend à la fois du paramétrage applicatif et de la stabilité de l’environnement informatique.

IPE : les informations produites par l’entité

Les IPE désignent les états, extractions ou fichiers utilisés par l’entité et par l’auditeur comme éléments probants. Il peut s’agir d’une balance âgée, d’un état des immobilisations, d’un export de ventes, d’un FEC ou d’un tableau issu d’un outil de consolidation. L’auditeur s’intéresse alors à l’exhaustivité et à l’exactitude de l’information : critères d’extraction, période couverte, droits de modification, rapprochement avec la comptabilité, traçabilité des retraitements manuels.

Comment se déroule la démarche d’audit du SI

La démarche n’est pas uniforme : elle dépend de la taille de l’entité, de la complexité du SI, du degré d’automatisation des flux et des risques identifiés. Elle suit toutefois une progression logique, de la compréhension des processus jusqu’à l’évaluation de l’impact sur l’opinion d’audit.

Prendre connaissance des flux et des applications clés

La première étape consiste à comprendre comment l’information circule. Quels outils génèrent les écritures ? Quelles interfaces alimentent la comptabilité ? Quels contrôles existent entre les systèmes ? Qui peut modifier les paramètres sensibles ? Cette phase peut s’appuyer sur des entretiens, des diagrammes de flux, des revues de procédures, des extractions de droits et l’observation des traitements de clôture.

Tester la conception puis le fonctionnement des contrôles

L’auditeur distingue la conception du contrôle et sa mise en œuvre effective. Un contrôle peut être bien décrit dans une procédure, mais mal appliqué ; à l’inverse, une pratique robuste peut manquer de formalisation. Les tests peuvent porter sur un échantillon de changements applicatifs, la revue des habilitations, la preuve d’un rapprochement d’interface, la restauration d’une sauvegarde ou l’analyse des exceptions dans un workflow.

Analyser les anomalies et ajuster les travaux d’audit

Les constats ne débouchent pas automatiquement sur une réserve. Ils sont appréciés selon leur nature, leur fréquence, leur impact potentiel et les contrôles compensatoires existants. Une faiblesse sur les accès à privilèges peut conduire à renforcer les tests de substance, à élargir l’analyse de données ou à demander des éléments probants complémentaires. L’objectif reste d’obtenir une assurance suffisante sur les comptes, pas de dresser un inventaire technique exhaustif.

Externalisation, SaaS et rapports d’assurance : les points de vigilance

De nombreuses entreprises externalisent tout ou partie de leur fonction informatique : hébergement, paie, facturation, ERP en mode SaaS, sauvegarde, infogérance ou outils de paiement. Cette externalisation ne transfère pas le risque d’audit hors du périmètre du commissaire aux comptes. Elle modifie surtout la manière d’obtenir des preuves.

Le rôle des rapports ISAE 3402

Lorsqu’un prestataire traite des données ayant un impact sur les comptes, un rapport d’assurance ISAE 3402 peut fournir des éléments utiles sur les contrôles de l’organisation de services. Un rapport de type I décrit la conception des contrôles à une date donnée ; un rapport de type II apporte en plus une appréciation sur leur fonctionnement sur une période. Le commissaire aux comptes doit toutefois vérifier si le rapport couvre bien les services utilisés, la période auditée et les contrôles pertinents pour les comptes.

Les risques à ne pas sous-estimer chez les prestataires

Le recours à un outil SaaS ou à un infogérant impose de clarifier les responsabilités : qui crée les utilisateurs, qui valide les droits, qui teste les changements, qui conserve les journaux, qui déclenche le plan de secours ? Une zone grise entre l’entreprise et le prestataire peut laisser apparaître des failles très concrètes, notamment sur la révocation des accès, le suivi des incidents, la disponibilité des données ou la conservation des preuves nécessaires à l’audit.

En pratique, un audit SI réussi ne se limite pas à cocher une liste de contrôles. Il relie les risques informatiques aux cycles comptables, hiérarchise les faiblesses selon leur impact financier et aide l’entreprise à renforcer son contrôle interne. Pour le commissaire aux comptes, c’est un levier essentiel pour sécuriser le jugement professionnel porté sur les comptes annuels.