Audit ITGC : types, exemples et méthode

Au titre de l'exercice 2024, les défaillances informatiques sont citées dans 60 % des attestations défavorables émises par les auditeurs américains sur le contrôle interne relatif à l'information financière, derrière le seul manque de ressources comptables (73 %). Ces chiffres proviennent de l'étude annuelle d'Ideagen Audit Analytics sur les publications SOX 404, reprise par EY dans ses priorités 2026 pour les comités d'audit. Deux ans plus tôt, l'informatique occupait la première place de ce classement.

La fiabilité des comptes se joue donc pour partie dans des paramètres d'habilitation, des procédures de mise en production et des journaux d'exécution. Les contrôles informatiques généraux (ITGC) relèvent à ce titre de la direction financière et de l'audit autant que de la direction des systèmes d'information.

Que sont les contrôles informatiques généraux (ITGC) ?

Les ITGC sont les contrôles qui portent sur les processus informatiques soutenant le fonctionnement continu de l'environnement de système d'information. La définition figure dans l'ISA 315 (Revised 2019) de l'IAASB, dont l'annexe 6 leur est entièrement consacrée. Leur objet est l'environnement dans lequel les traitements s'exécutent : qui accède au système, qui peut le modifier, comment les traitements tournent, comment les évolutions sont développées et livrées.

En France, la Compagnie nationale des commissaires aux comptes emploie l'expression « contrôles généraux informatiques » accompagnée du sigle anglais ITGC, tout comme CPA Canada dans ses ressources sur la NCA 315 révisée. Le sigle circule tel quel dans la littérature professionnelle francophone, aux côtés d'ITAC pour les contrôles applicatifs.

Un point de vocabulaire mérite d'être posé d'emblée. Les ITGC et la cybersécurité se recoupent largement sur la gestion des accès et des changements, mais leur finalité diverge. La cybersécurité protège l'entreprise contre une menace externe ou interne. Les ITGC garantissent que l'information financière produite par les systèmes est complète, exacte et attribuable à une personne identifiée. Une entreprise peut afficher un niveau de sécurité solide et présenter malgré tout des ITGC insuffisants au regard de l'audit des comptes, parce que les deux dispositifs ne répondent pas aux mêmes questions. Cette distinction structure tout le reste de la démarche, y compris le dispositif de contrôle interne dans lequel les ITGC s'inscrivent.

ITGC et contrôles applicatifs (ITAC) : la différence

Un contrôle applicatif s'exécute à l'intérieur d'une application, sur une transaction donnée : blocage d'une facture fournisseur dont le montant dépasse la commande, contrôle de cohérence sur un compte d'imputation, rapprochement automatique entre commande, réception et facture. Son fonctionnement est mécanique et reproductible.

Sa fiabilité dépend cependant de celle des ITGC qui gouvernent l'application. Un seuil de tolérance qu'un administrateur peut modifier sans approbation ni trace ne constitue pas un contrôle sur lequel un auditeur peut s'appuyer, quelle que soit la qualité de sa conception initiale.

La conséquence pratique est directe : un auditeur qui veut s'appuyer sur un contrôle automatisé commence par tester les ITGC de l'application concernée. Sans ce préalable, il repasse sur des tests de détail manuels, plus lourds et plus coûteux. 

Pourquoi les ITGC comptent pour la finance et l'audit

La norme AS 2201 du PCAOB énonce ce lien parmi les facteurs de risque d'un contrôle. Elle retient le degré de dépendance d'un contrôle à l'efficacité d'autres contrôles, dont les contrôles généraux informatiques, et précise qu'un contrôle automatisé présente généralement un risque plus faible lorsque les ITGC pertinents fonctionnent. Son annexe B va plus loin : l'auditeur peut alléger ses tests d'un contrôle automatisé d'un exercice sur l'autre, à condition que les contrôles généraux sur les changements de programme, les accès aux programmes et l'exploitation informatique restent efficaces et testés.

La cascade se lit alors dans les deux sens. Des ITGC efficaces permettent de réduire l'effort de test sur les contrôles automatisés. Des ITGC défaillants le font exploser, puisque chaque contrôle automatisé et chaque rapport issu du système perdent leur présomption de fiabilité. Au bout de la chaîne se trouve la qualification de faiblesse significative sur le contrôle interne relatif à l'information financière.

L'exposition augmente avec l'empreinte informatique des processus comptables. L'enquête SOX 2025 de KPMG, menée auprès d'environ 150 responsables de programmes SOX sur les données de l'exercice 2024, recense 40 systèmes en moyenne dans le périmètre de conformité, contre 17 deux exercices plus tôt, pour 546 contrôles clés testés. Dans le même temps, la part des contrôles entièrement automatisés reste à 17 %. L'essentiel du dispositif repose donc sur des contrôles manuels ou dépendants de données produites par les systèmes, ce qui ramène la question des ITGC au centre.

Les 4 domaines ITGC

La pratique d'audit regroupe les ITGC en quatre domaines. Le découpage est stable d'un référentiel à l'autre, ce qui en fait une base de cadrage utilisable telle quelle.

Ces quatre domaines ne pèsent pas de la même façon selon l'organisation. Une entreprise qui sous-traite son infogérance déplace une partie de l'exploitation vers un prestataire, ce qui déplace aussi la charge de preuve vers les rapports d'assurance de ce prestataire. Une entreprise en pleine migration ERP verra son risque se concentrer sur le cycle de vie et la reprise de données.

Exemples concrets de contrôles ITGC

Cinq contrôles reviennent dans la quasi-totalité des périmètres ITGC, quel que soit le secteur.

• Revue périodique des habilitations. Les propriétaires métier valident, à intervalle défini, la liste des utilisateurs disposant de droits sur les transactions financières sensibles, et les écarts constatés donnent lieu à un retrait tracé.
• Séparation des tâches informatique. Aucun profil ne cumule la création d'un tiers, la saisie d'une pièce et sa validation ; côté technique, aucun développeur ne dispose de droits de modification directe en production.
• Validation des mises en production. Chaque changement livré sur un système comptable porte une trace d'approbation fonctionnelle et technique, avec un lien vérifiable entre la demande initiale, le test de recette et la livraison.
• Supervision des traitements batch. Les échecs et reprises de traitements alimentant la comptabilité sont détectés, journalisés, analysés et clôturés, avec une attention particulière aux périodes de clôture.
• Sauvegardes et tests de restauration. La sauvegarde des données financières est exécutée selon la fréquence définie et fait l'objet de tests de restauration documentés, les sauvegardes non restaurables étant un cas fréquent.

Les référentiels applicables

Aucun référentiel unique ne définit les ITGC. Plusieurs corpus se combinent, et l'auditeur choisit celui qui sert d'ancrage selon le contexte.

Le COBIT 2019 de l'ISACA fournit la grille la plus détaillée côté gouvernance des systèmes d'information, avec 40 objectifs de gouvernance et de management. Quatre d'entre eux recouvrent directement les domaines ITGC : DSS05 pour les services de sécurité gérés, BAI06 pour la gestion des changements, DSS01 pour l'exploitation et BAI03 pour l'identification et la construction des solutions.

Le cadre COSO de contrôle interne publié en 2013, Internal Control, Integrated Framework, aborde le sujet par son principe 11, selon lequel l'organisation sélectionne et développe des activités de contrôle générales sur la technologie afin de soutenir l'atteinte de ses objectifs. C'est le rattachement normatif qui fait des ITGC une composante du contrôle interne et non une annexe technique. COSO a complété ce socle en février 2026 par une publication dédiée au contrôle interne sur l'IA générative, sans réviser le cadre de 2013.

Du côté de l'audit externe, la norme AS 2201 du PCAOB structure la démarche américaine, tandis que l'ISA 315 (Revised 2019) de l'IAASB fournit le socle international. En France, la NEP 315 révisée a été homologuée par arrêté du 13 novembre 2024, publié au Journal officiel du 19 novembre 2024, et s'applique aux missions de certification portant sur les exercices ouverts à compter de cette date. Elle renforce l'exigence de compréhension du système d'information de l'entité et des risques qui en découlent. La supervision de la profession relève depuis le 1er janvier 2024 de la Haute autorité de l'audit, qui a succédé au H3C.

Restent les normes de sécurité. ISO/IEC 27001 dans sa version 2022 encadre un système de management de la sécurité de l'information sur un périmètre choisi par l'organisation. Elle recoupe les ITGC sur les accès, les changements et la continuité, sans porter sur la fiabilité de l'information financière. Le même raisonnement vaut pour les textes européens de cybersécurité, traités dans notre article sur la conformité réglementaire : une certification ou une mise en conformité NIS2 ne dispense pas d'un audit ITGC, et n'en tient pas lieu.

Comment auditer les ITGC

La démarche suit quatre étapes, dans cet ordre.

Le cadrage du périmètre identifie les applications, bases de données, systèmes d'exploitation et interfaces qui contribuent à l'information financière. Un système exclu à tort du périmètre invalide l'ensemble des conclusions, et c'est le point où les programmes d'audit dérapent le plus souvent, notamment sur les outils périphériques et les développements spécifiques.

Les tests de cheminement retracent ensuite un cas réel de bout en bout : une demande d'accès accordée, un changement livré, un batch exécuté. L'objectif est de confirmer que le contrôle décrit dans la documentation correspond à ce qui se pratique.

Le test de conception évalue si le contrôle, tel qu'il est conçu, prévient ou détecte effectivement le risque visé. Une revue d'habilitations annuelle sur un périmètre de 4 000 utilisateurs, réalisée par un responsable qui approuve la liste sans consulter le détail, échoue à ce stade sans qu'il soit utile de tester son efficacité opérationnelle.

Le test d'efficacité opérationnelle vérifie enfin que le contrôle a fonctionné sur toute la période, sur la base d'un échantillon. Aucune norme de l'AICPA ni du PCAOB n'impose de taille d'échantillon. Le guide Audit Sampling de l'AICPA propose des repères pour les petites populations, de l'ordre de deux éléments pour un contrôle trimestriel et de deux à quatre pour un contrôle mensuel. Les fourchettes plus larges appliquées aux contrôles quotidiens relèvent des méthodologies de cabinets, ce qui explique leurs variations d'un intervenant à l'autre. Les logiciels d'audit interne facilitent la traçabilité de ces travaux, sans modifier la logique de test.

Les constats ITGC les plus fréquents

KPMG, dans son analyse d'avril 2024 sur la place des contrôles informatiques dans l'ICFR, recense les thèmes qui reviennent dans les opinions défavorables : privilèges excessifs, mots de passe faibles sur les comptes de service ou de prestataires partagés, surveillance insuffisante de l'usage des accès, retrait tardif des droits des salariés et prestataires partis ou mutés, super-utilisateurs en mesure de contourner les contrôles applicatifs, changements livrés sans autorisation ni test, absence de séparation entre les accès de développement et de production, inventaire incomplet des systèmes concernés par le reporting financier.

Le sondage SOX de Protiviti pointe le même foyer : les contrôles d'accès et la sécurité informatique constituent le domaine où les répondants rencontrent le plus de difficultés et de déficiences, souvent du fait de conflits de séparation des tâches ou de lacunes dans les revues d'accès et les procédures de départ.

Deux constantes se dégagent. La première tient au décalage entre la règle et son application : la procédure de retrait des accès existe, mais son délai d'exécution réel se compte en semaines. La seconde tient à la profondeur de la revue : les revues d'habilitations portent sur l'existence des droits et rarement sur leur utilisation effective, alors que c'est l'usage qui matérialise le risque, comme le montrent les chiffres sur la fraude interne et externe.

Du test ponctuel à la surveillance continue

Un audit ITGC annuel produit une photographie. Il établit qu'à la date de la revue, les habilitations étaient conformes et les changements documentés. Il ne dit rien des trois cent soixante autres jours, ni de ce que les détenteurs de ces accès ont fait de leurs droits.

C'est la limite structurelle de l'approche par échantillon. Un compte à privilèges correctement approuvé peut avoir servi à passer une écriture d'ajustement un soir de clôture. Une revue d'habilitations valide l'existence du droit, pas son usage. Seule l'analyse des transactions et des journaux d'activité relie les deux.

La surveillance continue répond à ce point précis en testant les données produites par les systèmes à chaque extraction. C'est la logique de la surveillance continue des contrôles, qui prolonge l'audit ITGC au lieu de s'y substituer. Supervizor se connecte aux ERP et exécute plus de 350 contrôles prêts à l'emploi sur l'ensemble des cycles financiers, dont un module dédié à l'activité utilisateur et à la séparation des tâches, sur la totalité des transactions plutôt que sur un échantillon. Le rapprochement entre les droits accordés et les opérations réellement passées devient alors un contrôle permanent, exploitable dans un dispositif de conformité comme dans un plan d'audit.

Conclusion

Les ITGC déterminent la valeur probante de tout ce qui est automatisé dans les processus comptables. Le point de départ d'un programme utile tient en deux questions : la liste des systèmes contribuant à l'information financière est-elle à jour, et les revues d'habilitations portent-elles sur l'usage des droits ou seulement sur leur existence. La réponse à la seconde question détermine si le dispositif détecte les écarts ou se contente de constater qu'ils étaient permis.