CHAPITRE 2 Principe et règles d’audit 2.1. Principe d’audit Le principe et les règles d’audit suivent logiquement l’exposé précédent. D’abord, comme dans toute branche de l’activité d’une entreprise, l’audit doit exister en informatique, et même davantage en fonction des vulnérabilités et des coûts qu’elle induit. Un audit informatique n’a de sens que si sa finalité est définie : contrôle fiscal, juridique, expertise judi- ciaire, vérification de l’application des intentions de la direction, examen de l’efficacité ou de la sécurité d’un système, de la fiabilité d’une application, etc.Objectifs et audit informatiques 67 Exemple.– Une « évaluation du système informa- tique », pourtant souvent proposée commercia- lement, n’a aucun sens. Le terme implique une notion de valeur, donc chiffrée, subjectivement avec une référence par conséquent, alors qu’aucune notation n’a de fondement objectif. Ne sont fondées que des approches par aspects sur objets, exprimées concrètement par « tel composant du système, sujet de la mission, présente telles qualités et tels défauts ». PRINCIPE.– Auditer rationnellement est expliciter les finalités de l’audit, puis en déduire les moyens d’investigation jugés nécessaires et suffisants. Pratiquement, c’est apprécier dans un but précis, et une situation concrète observée (le « comment »), l’application du principe et des règles (le « pourquoi »). 2.2. Règles d’audit Quel que soit le type de l’audit (interne ou externe, contractuel ou légal, etc.) ...
.1.2CHAPITRE2Principe et règles dauditPrincipe dauditLe principe et les règles daudit suivent logiquementlexposé précédent.Dabord, comme dans toute branche de lactivitédune entreprise, laudit doit exister en informatique,et même davantage en fonction des vulnérabilités etdes coûts quelle induit.Un audit informatique na de sens que si sa finalitéest définie: contrôle fiscal, juridique, expertise judi-ciaire, vérification de lapplication des intentions dela direction, examen de lefficacité ou de la sécuritédun système, de la fiabilité dune application, etc.
bOejtcfisteuaidtnifroamituqse76Exemple. Une «évaluation du système informa-tique», pourtant souvent proposée commercia-lement, na aucun sens. Le terme implique unenotion de valeur, donc chiffrée, subjectivementavec une référence par conséquent, alorsquaucune notation na de fondement objectif. Nesont fondées que des approches par aspects surobjets,expriméesconcrètementpar«telcomposant du système, sujet de la mission,présente telles qualités et tels défauts».IRCNPIEP.Auditerrationnellementestexpliciterles finalités de laudit, puis en déduire les moyensdinvestigation jugés nécessaires et suffisants.Pratiquement, cest apprécier dans un but précis, etune situation concrète observée (le «comment»),lapplication du principe et des règles (le«pourquoi»).2.2.RèglesdauditQuel que soit le type de laudit (interne ou externe,contractuel ou légal, etc.), la finalité est toujours de
Luaidtniofmrtaqieu86porter un jugement sur le management du systèmedinformation et lexécution de ses objectifs. Cestdonc la comparaison entre ce qui est observé (un actede management ou dexécution) et ce que celadevrait être, selon un système de références.lIetslciaruqeelujegemtneneptuesilimetrànueapprobation ou plus souvent à une condamnation, quiserait totalement inutile en soi aux audités, maispréciser ce quil aurait fallu faire, et ce quil faudrafaire pour corriger les défauts constatés.Exemple. Une conclusion peut être que ladocumentation dune application est globalementcompréhensible, mais quil faut la mettre à jourcar elle nest plus exactement en phase avec lamaintenance de la dernière année, qui a négligéce point.GEELR.Lauditinformatiqueconsisteàcompa-rer lobservation dun ou plusieurs objet(s), selonun ou plusieurs aspects, à ce quil(s) devrai(en)têtre, pour porter un jugement et faire desrecommandations.
aLâthceedluaidOtbeejucritsfeesttuadpiatrniffaoirtmetaimqeeunstédf96nieiquand lobjet et laspect le sont. Et elle ne doit pas endéborder.Exemple. Sil lui est demandé de vérifier lasécurité dune application, et quil en est satisfait,il est complètement indifférent de savoir si lesrésultats en sont exacts, car cest une question defiabilité; ou quils sont absolument inutiles, car ilsagit dadaptation.En effet, lauditeur ne doit jamais remettre en causela finalité de son audit en fonction de ce qui est plussimple, ou plus intéressant de faire, selon ses goûts.Il est beaucoup plus facile de formuler cette règle quede lappliquer: qui na tendance à la transgresser,surtout si des lacunes évidentes mais hors mission serévèlent?Les règles sont identiques à celles du management,sauf une, la faisabilité. En supposant que les moyensattribués sont suffisants, et sen assurer fait partie dela négociation préalable, et que lauditeur estcompétent, la non-faisabilité impliquerait que lesystème est incontrôlable, pratiquement par absence
Luaidtniofmrtaqieu07de documentation. Et alors la conclusion immédiateest quil a tous les défauts possibles. LExemple. Un cas réel est celui dune entreprisedont il était demandé dexaminer la fiabilité dusous-système comptable, avec une prévision deplusieurs semaines de travail: en quelquesheures, lapplication écrite en langage proche dela machine, aucunement documentée, reposantsur un système de bases de données et ungestionnaire de télécommunications maison, avecun nombre très réduit dinformaticiens compé-tents, tous indisponibles (ils étaient toujoursabsorbés par la réparation de pannes) devaitconclure à la non-fiabilité et en prime à toutes lesobservations critiques concernant les aspects vusplus haut.EGLER.Lauditinformatiqueesttoujoursfaisable (contrairement au management delinformatique).ertaavlidadutipuettêerasszecmolpxe,eetodnil doit obéir aux mêmes règles que le management, eten particulier être découpé en fonctions conduisantc
bOejtcfisteuaidtnifroamituqse17de façon arborescente à un plan avec des étapessignificatives de conclusions partielles. Mais lemaillon le plus faible de sa démonstration est bienentendu celui qui remet tout en cause.CExemple. Si la mission concerne la sécuritédune application de gestion du personnel,lauditeur peut éluder avec accord du demandeurles questions de plan et de budget; il lui faudraexaminer à fond mais sous le seul aspect desécurité et dans la mesure où ils concernent cetteapplication, les matériels et logiciels, lesressources humaines, les contrats, les méthodes,et enfin les réalisations et leur exploitation. Celafait, et puisquil a examiné tous les objetsconcernés selon laspect demandé, lesconclusions de lauditeur seront certaines etinébranlables GEELR.Lesmoyensetactionsdelauditeurdoivent être adaptés exclusivement maisexhaustivement au sujet de laudit.leamilpqieuanuterllmenetlvélotuiivéto(vure-ture de recommandations sur lavenir, et non simple
Luaidtniofmrtaqieu72constat déchecs), la cohérence et la planification desressources, bien entendu lexactitude (fiabilité) desconclusions. La sécurité de laudit ne sappliquequaux documents de travail et aux rapports, à leurnon-diffusion hors destinataires autorisés, donc doitaller de soi.Lavancement des travaux doit être logique commeune démonstration mathématique, donc arborescentedans un sens voisin du précédent: «pour prouvertelle affirmation, il faut sassurer de tels et tels faits;et pour prouver tel fait, il faut le décomposer en telset tels points, etc.».Exemple. Pour prouver quune application degestion du personnel est sûre, et à supposer que ledemandeur ne soit pas intéressé par un examen deses finalités ni des moyens financiers en cedomaine, il faudra examiner les sécurités dumatériel et du logiciel de base, y compris lesréseaux, utilisés par cette fonction, examinertoujours sous le seul angle de la sécurité lesdiagrammes de circulation dinformation et lesresponsabilités (fiches de fonction) de chaque
Objectifs et audit informatiques73membre du personnel impliqué, les méthodes etles programmes sensibles de lapplication, lessaisies dinformations, les recyclages danoma-lies, la bibliothèque.Alors seulement lauditeur pourra affirmer avoir faitune étude exhaustive et trouvé toutes les faillespossibles.2.3.DéontologieIl sensuit que lauditeur doit obéir, de soi-même caren dehors des responsabilités juridiques rien ne lyoblige, à une déontologiecertaine. Cest ainsi quil:tiodsinterdire de cumuler audit et conseil, sur unemême question: comment auditer quelque chose quelon a conseillé, ou bien recommander de prendre sonconseil? Pourtant il existe des sociétés proposantsimultanément conseil, service et audit; lintérêt deproposer un audit qui recommandera de prendre unconseil de réalisation, puis le conseil proposant unservice, le tout effectué par la même société, laisse àréfléchir sur lobjectivité dans lintérêt du client. On
Luaidtniofmrtaqieu47a même vu un constructeur proposer des auditsgratuits, dont la conclusion était assez attendue;garantir, même implicitement par simple accep-tation dune tâche, quil a, par lui-même ou grâce àune équipe sur laquelle il peut compter, lescompétences nécessaires; elles ne sont aucunementsupérieures à celles des réalisateurs, mais différentes,sur un substrat technique partiellement commun; ilne sagit que dattitudes, presque purement psycho-logiques: lauditeur na pas besoin du souffle ni desconnaissances approfondies quil faut pour mener àbien une réalisation, mais il doit être rapide, précis,avec juste les connaissances ponctuelles nécessaireset suffisantes;sintéresser au système dinformation dans sonensemble, cest-à-dire pas aux seuls éléments auto-matisés, ou au contraire à ceux qui ne le sont pas;fournir des conclusions motivées, utiles, sur lobjetet laspect, ainsi que la période de temps qui a dû êtreconsidérée, qui ont été les éléments de sa mission.Des considérations générales ou non explicitementjustifiées sont irrecevables; en particulier des termesaussi vagues que «diagnostic», ou, pire «évaluation»,
bOejtcfisteuaidtnifroamituqse57qui suggère une quantification, sont inacceptablessauf éventuellement dans un contexte précis;et ce, dans le délai imparti et accepté.Le domaine de la tâche dun auditeur est donc trèsrigoureusement défini en termes dobjets, daspects,et de cadre temporel, et sa démarche est dunedémonstration rigoureuse et exhaustive.Les sujets daudit doivent être maintenant évidents. Ila paru naturel dadopter une structure par objets; onaurait pu aussi faire un plan par aspects.2.4.ConsidérationssurlerreurSi lerreur nétait pas humaine, il ny aurait pasbesoin dauditeur. Or non seulement elle lest, maisen informatique les machines sont impitoyables pourla révéler au grand jour.Exemple. Lauditeur ne recherche sauf excep-tion que lerreur, ou plutôt les lacunes de contrôleoù celle-ci peut se glisser. Mais il lui arrive deconstater la fraude ou le sabotage, qui en fait nesont pas concrètement pires en termes de valeur.
Luaidtniofmrtaqieu67Elle provient de défaillances dans la représentationde la réalité et la compréhension des observations:rapfaute de connaissance dinterprétation et dereprésentation;faute concernant les hypothèses déduites (modèlemental inexact, incomplétude ou ambiguïté) etinduites (suppositions erronées);choix des objectifs (contradictoires, hors délais,superflus, faute de raisonnement);choix des solutions (saturation mentale, analogieinjustifiée, confusion);réalisation (erreurs de communication, de procé-dure, de vérification).Et en informatique, il ne faut compter sur aucuneindulgence, aucune tolérance, dès lors que la solutionest automatisée.2.5.ConclusionsurlauditinformatiqueLe principe et ces règles nauraient pas de raisondêtre exposés sils ne pouvaient être mis en uvre.