ISA 315 révisée : la checklist des contrôles informatiques que votre commissaire aux comptes attend désormais

Pourquoi votre auditeur pose soudain des questions sur l’informatique

Jusqu’en 2021, un commissaire aux comptes pouvait auditer une PME camerounaise sans jamais demander qui avait le droit de créer un fournisseur dans l’ERP. La norme ISA 315 révisée en 2019, applicable aux audits des exercices ouverts à compter du 15 décembre 2021, a changé cela. Elle impose à l’auditeur d’identifier les applications informatiques et les autres composantes de l’environnement informatique qui interviennent dans la production de l’information financière, d’évaluer les risques liés à leur utilisation, et de comprendre les contrôles généraux informatiques qui répondent à ces risques.

La norme définit ces contrôles généraux informatiques comme les contrôles afférents aux processus informatiques de l’entité qui contribuent à assurer de manière permanente le bon fonctionnement de l’environnement informatique, notamment le maintien du fonctionnement efficace des contrôles du traitement de l’information et l’intégrité de celle-ci. En clair : si personne ne maîtrise qui accède à l’ERP, qui le modifie et comment il est sauvegardé, aucun contrôle automatisé de l’ERP ne peut être considéré comme fiable.

La conséquence pratique est financière. Quand l’auditeur ne peut pas s’appuyer sur les contrôles automatisés, il doit augmenter ses tests de détail sur les transactions. Une mission qui tenait en deux semaines en demande trois, et la facture suit.

Les quatre domaines que la norme attend

La norme organise les contrôles généraux informatiques autour de quatre processus. Les douze preuves ci-dessous sont celles que nous demandons systématiquement en audit SI, et que nous recommandons aux directions financières de préparer avant l’arrivée du commissaire aux comptes.

Gestion des accès

1. Liste nominative des utilisateurs de chaque application financière, avec leur profil, extraite de l’application elle-même et non d’un tableur. Les comptes génériques (« compta1 », « admin ») doivent être justifiés ou supprimés.
2. Matrice de séparation des tâches montrant qu’une même personne ne peut pas créer un fournisseur et valider son paiement, ni saisir une écriture et la valider. Dans une PME où la direction financière compte trois personnes, la matrice existe quand même ; elle documente les cumuls et le contrôle compensatoire du dirigeant.
3. Procédure et preuves d’arrivée et de départ : qui demande un accès, qui l’approuve, et la preuve que les comptes des salariés partis dans l’exercice ont été désactivés dans la semaine.
4. Revue périodique des droits signée par un responsable métier, au moins une fois par exercice.

Gestion des changements

5. Journal des modifications apportées aux applications financières dans l’exercice : montées de version, paramétrages structurants (plan de comptes, taux de TVA, schémas d’écriture), développements spécifiques.
6. Preuve de test et d’approbation avant mise en production pour chaque changement du journal. Un courriel du directeur financier validant la recette suffit, à condition qu’il existe.
7. Séparation des environnements : les tests ne se font pas dans la base de production. Pour les petites structures qui n’ont qu’une base, la compensation est une sauvegarde datée avant chaque changement et une revue des écritures après.

Exploitation informatique

8. Politique de sauvegarde et preuves de restauration. La preuve qui compte n’est pas que la sauvegarde tourne, c’est qu’une restauration a été testée dans l’exercice et qu’elle a fonctionné.
9. Suivi des traitements automatiques : interfaces entre la paie et la comptabilité, entre la facturation et l’ERP, entre la banque et le rapprochement. Qui surveille les rejets, où sont-ils tracés, qui les corrige.
10. Gestion des incidents affectant les applications financières, avec la liste des incidents de l’exercice et leur résolution.

Acquisition et développement

11. Cahier des développements spécifiques dans l’ERP, avec pour chacun l’objectif, l’auteur, la date de mise en production et le test réalisé. C’est le point le plus souvent vide dans les PME qui ont fait développer des états ou des interfaces sur mesure.
12. Contrat et clauses de réversibilité avec le prestataire qui héberge ou maintient l’application, incluant la localisation des données et les engagements de disponibilité.

Ce que l’auditeur fait de ces preuves

Il ne les archive pas. Il les utilise pour décider de sa stratégie. Si les contrôles généraux informatiques sont conçus et appliqués, il peut tester les contrôles automatisés de l’ERP, par exemple le blocage d’une facture sans bon de commande, sur un échantillon réduit, puis s’appuyer sur eux pour tout l’exercice. S’ils sont absents, il doit considérer que n’importe quelle écriture a pu être modifiée sans trace, et ses tests substantifs s’alourdissent en proportion.

C’est aussi ce qui explique l’intérêt d’un audit SI en amont de la mission légale : il identifie les déficiences quand il est encore temps de les corriger dans l’exercice, et non quand elles se transforment en point du rapport. Notre pratique d’audit SI couvre exactement ce périmètre, et notre plateforme HOLOS permet aux cabinets de documenter cette évaluation des risques dans le dossier d’audit ISA.

Pour les ERP que nous déployons

Sage X3, Odoo et Dynamics 365 disposent nativement de la journalisation des accès, de la gestion des profils et de la traçabilité des modifications de paramétrage. La difficulté n’est presque jamais technique : elle tient à ce que ces fonctions soient activées, que leurs journaux soient conservés et que quelqu’un les revoie. C’est pour cela que nos déploiements incluent la matrice des droits dans le dossier de conception et que la revue des accès figure dans le plan de run. Un ERP livré sans cela est un ERP que l’auditeur ne pourra pas utiliser.