Guide d analyse des risques informatiques

(1)

Infrastructure IT Systèmes

IT de base Applications IT Processus

métiers

Trainin g

des risques informatiques

Support de travail pour les auditeurs de PME

8.9.2011

(2)

(3)

1

Table des matières

Auteurs:

Comité technique informatique de la Chambre fiduciaire Gestion de projet:

Peter R. Bitterli et Peter Steuri

Graphisme et mise en page: Felice Lutz, ITACS Training AG

Table des matières 1

Vue d’ensemble et délimitation 2

Introduction 4

Guide d’analyse des risques informatiques 6

Phase 1: Evaluation globale des risques 8

Phase 2: Contrôle relatif à l’utilisation de l’informatique 15

L’IT-Check comme «combinaison» des phases 1 et 2 19

Indications concernant les audits IT approfondis 21

Conclusion 24

Questionnaire Phase I (Annexe 1) 25

Questionnaire Phase II (Annexe 2) 27

(4)

1 Vue d’ensemble et délimitation

Délimitation de l’approche

Dans le cadre des procédures d’audit orientées processus ou résultat et basées sur l’utilisation d’applications informatiques (IT), il est essentiel de prendre en compte tous les domaines importants, y compris les domaines IT spécifiques ayant une influence significative sur l’objectif de l’audit. Pour y parvenir, une approche d’audit intégrée (auditeur et auditeur IT) est nécessaire. L’absence de procédure concertée entre auditeurs et auditeurs IT constitue à cet égard un risque élevé.

Afin de prévenir ce risque d’audit, les membres du Comité technique informatique de la Chambre fiduciaire ont élaboré deux guides. Ceux-ci reposent sur un modèle à quatre couches qui présente les principales interactions de manière schématique et simplifiée. Dans la réalité, les interactions peuvent être beaucoup plus complexes. La schématisation permet de mieux appréhender les deux approches.

La figure ci-dessus montre, sous forme simplifiée, le modèle en couches utilisé dans les deux approches élaborées par le Comité technique informatique. Chacune des quatre couches représente un type de processus et de ressource.

• La couche supérieure (bleue) contient les principaux processus (manuels) de l’entreprise, présentés typiquement par domaines d’activité et subdivisés en sous-processus et en activités individuelles.

• La deuxième couche (rouge) contient les éléments automatisés des processus de l’entreprise, c’est-à-dire les applications (IT) à proprement parler. A l’exception peut-être des PME de petite taille, la majorité des opérations commerciales dans toutes les entreprises est traitée à l’aide d’applications IT.

• La troisième couche (jaune) contient les systèmes IT de base. Ce terme recouvre une grande diversité de plates-formes possibles supportant les applications de la deuxième couche. Exemples: systèmes de gestion de base de données (p. ex. SQL, Oracle), composants de base d’applications intégrées (p. ex. SAP Basis) ou systèmes plus techniques (p. ex.

Middleware).

• La couche inférieure (verte) contient les éléments d’infrastructure informatique. Pour l’essentiel, cette couche contient

Contrôles d’applications IT

• Intégralité

• Exactitude

• Validité

• Autorisation

• Séparation des fonctions

Contrôles IT généraux

• Environnement de contrôle IT (polices, directives)

• Développement de programmes

• Modifications IT

• Exploitation IT

• Gestion des accès

• Sécurité des systèmes

• Sécurité des données

non couvert par la méthodecouvert par la méthode _Processusmétier / transactio

ns

Applications finan cières

Middlewar

e / base de do nnées

Systèmes d’exploitatio n / réseau

Modèle à quatre couches

(5)

3

Guide d’audit des applications informatiques

Le «Guide d’audit des applications informatiques» publié en 2008 est aujourd’hui disponible en allemand (www.treuhand- kammer.ch), en français (www.afai.fr) et en anglais (www.isaca.ch). Il traite principalement des deux couches supérieures, c’est-à-dire des contrôles basés sur l’utilisation d’applications informatiques au sein des processus métiers ainsi que des applications sous-jacentes.

L’approche présentée est destinée à aider l’auditeur financier à développer une approche d’audit intégrée et à recentrer la procédure d’audit de manière plus efficace et plus ciblée sur les risques, en intégrant l’audit des processus métiers pertinents et des applications correspondantes. L’approche commence donc avec l’analyse des états financiers de l’entreprise et se termine par l’appréciation de l’impact des résultats d’audit sur ces états financiers.

Cette analyse des états financiers de l’entreprise lie les principales positions comptables aux processus métiers pertinents ou, plus concrètement, détermine les flux de traitement des données à l’origine des principales positions comptables et des applications de base qui supportent ces flux.

Une fois les applications de base identifiées, l’auditeur s’intéresse à la qualité du système de contrôle. Il détermine d’abord si la conception du système de contrôle est adaptée à la situation de risque actuelle des processus de l’entreprise et enfin si les contrôles prévus sont implémentés et sont efficaces.

L’évaluation du système de contrôle des processus métiers pris en compte dans le cadre de l’audit permet à l’auditeur de savoir s’il peut s’appuyer sur les procédures et les applications de base à l’origine des principales positions comptables et, le cas échéant, de définir l’étendue des procédures d’audit orientées résultat supplémentaires qu’il doit effectuer.

Guide d’analyse des risques informatiques

Le présent «Guide d’analyse des risques informatiques» traite principalement des deux couches inférieures, c’est-à-dire de l’infrastructure IT et des processus IT sous-jacents, mais aussi des processus IT généraux relatifs à la maintenance et au développement des applications IT de l’entreprise au sein de la deuxième couche. Le guide analyse en outre un certain nombre de problématiques liées aux deux couches supérieures afin de procéder à une évaluation globale de la situation en termes de risques.

Le «Guide d’analyse des risques informatiques» établit une approche standard pour:

• l’identification des risques inhérents à l’utilisation de l’informatique dans l’entreprise;

• le recensement et l'évaluation des «contrôles IT généraux» ainsi que l’utilisation de l’informatique au sein des petites et moyennes entreprises et organisations.

Le «Guide d’analyse des risques informatiques», qui constitue un support de travail facultatif, fournit ainsi à l’auditeur les

informations sur l’utilisation de l’informatique nécessaires à la planification stratégique de l’audit.

(6)

2 Introduction

Importance de l’informatique pour le SCI

Conformément à l’art. 728a CO, l’organe de révision doit vérifier et confirmer, à partir de l’exercice 2008, s’il existe un système de contrôle interne (SCI) dans les entreprises ayant une importance économique soumises à un contrôle ordinaire.

Dans bon nombre de petites et moyennes entreprises, on observe que l’étendue et le contenu, mais aussi l’utilité concrète du SCI, sont encore sources d’incertitudes et de questions. Ceci est valable tant pour le SCI au niveau de l’entreprise et des processus que, dans une plus large mesure encore, pour les contrôles IT.

La Norme d’audit suisse «Vérification de l’existence du système de contrôle interne» (NAS 890) définit comme suit l’importance de l’informatique pour le système de contrôle interne:

«Plus le processus de tenue de la comptabilité et d’établissement du rapport financier dépend de systèmes IT et plus le risque que des erreurs trouvent leur origine dans la mise en place et l’utilisation des systèmes IT est élevé, plus les contrôles dans le domaine de l’informatique sont importants.»

Utilisation de l’informatique dans les PME

Les exigences des PME en matière d’informatique ne sont pas très différentes de celles des grandes entreprises: il est souvent indispensable de recourir à des applications recouvrant un large éventail de fonctions et requérant une disponibilité et une sécurité importantes pour assurer l’efficacité et la fiabilité des processus de l’entreprise.

Par rapport aux grandes entreprises, dont les services informatiques sont dotés d’un savoir-faire et de capacités élevés, les PME – bien que leurs systèmes et leur infrastructure IT soient généralement «clairs» et que les applications de base consistent de logiciels standard – sont souvent exposées aux risques «typiques» suivants:

• absence de savoir-faire en matière d’applications IT ainsi que de flux de données et de valeurs (interfaces), d’où une utilisation des logiciels inefficace et sujette aux erreurs, des faiblesses dans les contrôles internes et une dépendance élevée vis-à-vis de partenaires externes (fournisseurs);

• concentration importante du savoir-faire au niveau de quelques personnes, ce qui s’accompagne très souvent de processus IT peu structurés et peu documentés, d’où une dépendance élevée vis-à-vis de ces personnes clés;

• pas de séparation des fonctions entre la comptabilité et l’informatique, notamment parce que dans les petites entreprises la responsabilité et parfois aussi l’exécution dans ces deux domaines relèvent de la même personne;

• protection appropriée des accès au niveau du réseau et du système d’exploitation, cependant au sein des applications les droits d’accès sont peu différenciés, des mots de passe peu sûrs sont utilisés et il n’y a pas de changement périodique des mots de passe;

• présence d'applicatifs Excel ou Access et de solutions individuelles installées par certains utilisateurs sur leur PC et peu documentées; leur développement, leur évaluation, leur fonctionnement et, souvent, leur utilisation (en particulier concernant les chiffres clés et le MIS) dépendent entièrement de cette seule personne;

• faiblesses en termes de sécurité physique (accès, détection de la fumée et des incendies, climatisation et alimentation

(7)

5

Le SCI dans le domaine IT

Dans le domaine IT, un SCI global comprend des objectifs de contrôle et des contrôles à différents niveaux:

• Entreprises:

stratégie, organisation et personnel IT, gestion des risques et de la sécurité ainsi que pilotage et gestion de projets IT;

• Processus de l’entreprise:

organisation structurelle et opérationnelle et contrôles principalement au niveau des processus de l’entreprise ayant une influence sur les flux de données et de valeurs ainsi que sur la présentation des comptes et le rapport financier;

• Applications IT:

contrôles lors de la saisie, de l’entrée, du traitement et du résultat des transactions et des données ainsi que contrôles au niveau des interfaces entre les applications IT;

• Exploitation IT:

contrôles lors du développement et de la modification de programmes, de l’exploitation et de la configuration des moyens

IT, de la sécurité des systèmes et des données et de la surveillance de l’informatique.

(8)

3 Guide d’analyse des risques informatiques

Considérations initiales

Le «Guide d’analyse des risques informatiques» a pour but d’aider l’auditeur à identifier et à évaluer, dans les petites et moyennes entreprises et organisations, les risques éventuels liés à l’utilisation de l’informatique. L’auditeur peut ainsi tirer des conclusions qui lui serviront pour planifier et exécuter l’audit, mais aussi pour décider s’il doit faire appel ou non à un auditeur IT spécialisé.

L’approche couvre les «contrôles informatiques généraux (IT)» mentionnés dans la Norme d’audit suisse NAS 890

«Vérification de l’existence du système de contrôle interne». Elle se concentre sur les domaines ayant une importance directe et indirecte pour la tenue et la présentation des comptes et aborde aussi un certain nombre d’autres domaines.

L’approche est indépendante du type de contrôle (ordinaire ou restreint); elle se fonde sur l’importance que revêt l’informatique pour l’entreprise ainsi que sur la tenue et la présentation des comptes de celle-ci.

Les prescriptions juridiques et réglementaires concernant l’utilisation de l’informatique et son contrôle ne sont pas prises en compte dans le «Guide d’analyse des risques informatiques», mais elles peuvent parfaitement constituer une raison essentielle de faire évaluer l’utilisation de l’informatique par un auditeur IT spécialisé.

Aperçu du contenu

Phase 1: Evaluation sommaire des risques ➔ voir chapitre 4

La phase 1 correspond à une évaluation des risques et des interdépendances liés à l’utilisation de l’informatique.

L’évaluation ne doit pas impérativement être exhaustive et précise en tous points, mais elle doit mettre en lumière le besoin de réaliser un contrôle complémentaire – et plus détaillé – de l’utilisation de l’informatique.

A l’issue de la phase 1, l’auditeur peut décider, sur la base de cette première évaluation des risques, si l’exécution de la phase 2 est nécessaire.

Phase 2: Contrôle relatif à l’utilisation de l’informatique ➔ voir chapitre 5

La phase 2 correspond à un contrôle vaste et détaillé des forces et des faiblesses liées à l’utilisation de l’informatique.

Le traitement des questions/du questionnaire de la phase 2 peut s’effectuer tant dans le cadre de la planification stratégique de l’audit que dans celui de l’audit (intermédiaire) proprement dit.

A l’issue de la phase 2, les conclusions tirées par l’auditeur permettent à celui-ci de décider si un audit IT complet doit être

effectué et dans quels domaines.

(9)

7

L’IT-Check comme «combinaison» des phases 1 et 2 ➔ voir chapitre 6

Le contenu des phases 1 et 2 peut, notamment quand le contrôle lors de chaque phase est effectué parallèlement par le même auditeur, être regroupé dans un IT-Check.

Ce que le «Guide d’analyse des risques informatiques» n’est pas

Le «Guide d’analyse des risques informatiques» ne constitue pas une analyse complète des risques. Il s’agit plutôt d’un outil de travail destiné principalement à la planification stratégique de l’audit qui peut être mis en œuvre efficacement. Il permet une identification et une évaluation raisonnables des risques liés à l’utilisation de l’informatique.

Le «Guide d’analyse des risques informatiques» n’est pas un guide pour un audit informatique approfondi; selon les auteurs du guide, ce dernier doit être effectué par des auditeurs IT spécialisés. En outre, il existe des approches d’audit globalement reconnues, comme par exemple l’IT Audit Framework de l’ISACA et l’IT Governance Assurance Guide basé sur le C

obi

T. Les grands cabinets d’audit utilisent par ailleurs des approches et des documents de travail spécifiques à l’entreprise.

(10)

Positionnement

Le traitement des questions/du questionnaire de la phase 1 doit s’effectuer dans le cadre de la planification stratégique de l’audit. Les risques liés à l’utilisation de l’informatique peuvent ainsi être identifiés à temps et les conclusions en découlant peuvent être intégrées dans la planification de l’audit.

La phase 1 correspond à une évaluation des risques et des interdépendances liés à l’utilisation de l’informatique.

L’évaluation ne doit pas impérativement être exhaustive et précise en tous points, mais elle doit mettre en lumière le besoin de réaliser un contrôle complémentaire – et plus détaillé – de l’utilisation de l’informatique.

Procédure et parties prenantes

Le contrôle lors de la phase 1 doit permettre de déterminer l’importance que revêt l’informatique dans l’entreprise.

Les réponses aux 16 questions permettent de conclure si l’utilisation de l’informatique engendre pour l’entreprise des risques accrus qui sont à prendre en compte lors de la planification stratégique de l’audit.

Le questionnaire de la phase 1 est remis au client au préalable et rempli par les responsables de la comptabilité et de l’informatique. La revue du questionnaire effectuée par l’auditeur avec des représentants de l’entreprise devrait prendre environ une heure.

Il est ainsi possible d’évaluer dans un laps de temps raisonnable, sur la base de faits clairs, si un contrôle approfondi portant sur les risques IT, c’est-à-dire le déclenchement de la phase 2, s’impose.

Questionnaire / Critères

Le questionnaire contient cinq domaines thématiques; chaque domaine thématique comporte entre une et cinq questions.

Exploitation et IT

• Stratégie de l’entreprise et utilisation de l’informatique

• Degré d’innovation dans l’utilisation de l’informatique

• Dépendance par rapport à la disponibilité des moyens informatiques

Organisation interne et contrôle

• Gestion des risques

• Système de contrôle interne

• Sensibilisation à la sécurité informatique

• Séparation des fonctions

• Suppléance et savoir-faire en matière d’applications au sein du service de comptabilité

Applications IT

• Logiciels comptables

• Modiﬁcations dans les applications de base

• Intégration des ﬂux de valeurs dans la comptabilité

• Erreurs de programme dans les applications de base

Exploitation IT

• Sécurité opérationnelle des moyens informatiques

Audit indépendant de l’informatique

4 Phase 1: Evaluation globale des risques

(11)

9

Exploitation et IT

Ce domaine thématique permet de déterminer l’importance que revêt l’informatique pour l’entreprise. Il s’agit de savoir dans quelle mesure la stratégie de l’entreprise repose sur l’utilisation de moyens informatiques et dans quelle mesure les processus primaires de l’entreprise dépendent de la disponibilité des moyens informatiques.

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4

Stratégie de l’entreprise et utilisation de l’informatique

La stratégie de l’entreprise repose principalement sur l’utilisation d’Internet et des nouvelles technologies ainsi que sur l’échange actif d’informations via des réseaux de données.

La stratégie de l’entreprise repose en partie sur l’utilisation d’Internet et des nouvelles technologies; les processus importants de l’entreprise se basent sur l’échange d’informations via des réseaux de données.

La stratégie de l’entreprise dépend peu des nouvelles technologies, mais les processus importants de l’entreprise utilisent déjà ces technologies.

La stratégie de l’entreprise ne dépend pas des nouvelles technologies (p. ex. Internet ou e-commerce).

Degré d’innovation dans l’utilisation de l’informatique

L’entreprise utilise une infrastructure IT moderne et complexe et s’adapte clairement aux nouvelles technologies avant l’ensemble du secteur.

L’entreprise utilise une infrastructure IT complexe et s’adapte aux nouvelles technologies sans retard.

L’entreprise utilise une infrastructure IT étendue, comprenant dans une large mesure des composants standard, et ne s’adapte aux nouvelles technologies que lorsqu'elles sont matures.

L’entreprise utilise une infrastructure IT simple, comprenant dans une large mesure des composants standard; l’infrastructure IT est plutôt en marge par rapport aux développements technologiques.

Dépendance par rapport à la disponibilité des moyens informatiques

La disponibilité des moyens informatiques est un facteur critique pour l’exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est inférieur à quatre heures.

La disponibilité des moyens informatiques est importante pour l’exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre quatre heures et deux jours.

La disponibilité des moyens informatiques est parfois importante pour l’exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre deux jours et une semaine.

La disponibilité des moyens informatiques n’est pas critique pour l’exploitation (activités de front-office) et les processus primaires internes;

une défaillance supérieure à une semaine semble acceptable.

(12)

Organisation interne et contrôle

Ce domaine thématique permet d’évaluer la gestion des risques et le système de contrôle interne, la sensibilisation à la sécurité des données, la séparation des fonctions entre l’informatique et les différents services spécialisés ainsi que le savoir- faire et la suppléance au sein du service de comptabilité.

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4

Gestion des risques Il n’y a pas de gestion des risques identifiable; des mesures ad hoc sont mises en œuvre pour réduire les risques.

Il y a une gestion des risques ponctuelle, spécifique aux applications et partiellement documentée; les mesures de réduction des risques en découlant ne sont pas (facilement) identifiables.

Il y a une gestion des risques formalisée au niveau de toute l’entreprise; elle est documentée et actualisée périodiquement et les mesures de réduction des risques en découlant sont clairement identifiables.

Il y a une gestion des risques formalisée au niveau de toute l’entreprise; elle est documentée et actualisée chaque année et les risques sont clairement réduits.

La gestion des risques est complétée par une auto- évaluation des contrôles mis en place.

Système de contrôle

interne Un système de contrôle

interne (SCI) est difficilement identifiable ou inexistant.

Il y a un SCI ponctuel, spécifique aux domaines d’activité; le niveau de documentation et d’actualisation est toutefois peu clair.

Il y a un SCI formalisé au niveau de toute l’entreprise;

il est documenté et actualisé périodiquement.

il est documenté et actualisé chaque année. Le SCI est complété par une auto- évaluation des contrôles mis en place.

Sensibilisation à la

sécurité de l’information Les collaborateurs ne sont pas informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l’information.

Les collaborateurs sont informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l’information.

Les collaborateurs sont informés de manière répétée de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l’information et sont formés de manière appropriée.

Les collaborateurs sont formés systématiquement et le respect des exigences internes et externes en matière de sécurité de l’information est contrôlé régulièrement.

Séparation des fonctions Il y a uniquement une séparation des fonctions sommaire et informelle; il existe (également eu égard à l’informatique) des fonctions couvrant plusieurs services.

Il y a une séparation des fonctions entre l’informatique et les domaines d’activité; les fonctions au sein des services spécialisés ne sont parfois pas séparées.

Au sein des domaines d’activité, une séparation fonctionnelle des fonctions est assurée; celle-ci est documentée dans les descriptions des tâches, mais n’est pas contrôlée.

Au sein des domaines d’activité, une séparation fonctionnelle des fonctions est systématiquement assurée; celle-ci est documentée dans les descriptions des tâches et contrôlée en continu.

Suppléance et savoir-faire en matière d’applications au sein du service de comptabilité

Seule une suppléance sommaire est assurée au sein de l’entreprise; l’absence de certaines personnes engendre des problèmes déjà au niveau des activités quotidiennes habituelles.

Des suppléances sont prévues pour les fonctions importantes, mais la formation est quasi inexistante; l’absence de certaines personnes a une incidence sur les activités quotidiennes habituelles après quelques jours; la résolution des problèmes et des incidents n’est pas possible en cas de défaillance.

Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; les activités quotidiennes habituelles sont assurées; la résolution des problèmes et des incidents est cependant difficile et engendre des retards.

Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; il y a une documentation correspondante; les activités quotidiennes habituelles et la résolution efficace des problèmes sont assurées.

(13)

11

Applications IT

Ce domaine thématique permet d’évaluer les logiciels comptables et les applications de base ainsi que leur degré d’intégration et leur qualité.

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4

Logiciels comptables L’application comptable a été

développée en interne. Pour la comptabilité, des logiciels standard paramétrables disposant de possibilités de programmation individuelle sont utilisés.

Pour la comptabilité, des logiciels standard disposant uniquement de possibilités de paramétrage et de programmation individuelle limitées sont utilisés.

Pour la comptabilité, des logiciels standard sans possibilités de paramétrage et de programmation individuelle sont utilisés.

Modifications dans les

applications de base Les applications de base ont été remplacées au cours de l’exercice précédent ou actuel et les «anciennes» données ont été migrées.

Des parties essentielles des applications de base ont été remplacées au cours de l’exercice précédent ou actuel et les données ont été migrées.

Des parties essentielles des applications de base ont été modifiées (p. ex. changement de version) ou étendues au cours de l’exercice précédent ou actuel.

Les applications de base n’ont été que légèrement modifiées ou étendues au cours de l’exercice précédent ou actuel.

Intégration des flux de valeurs dans la comptabilité

Pour les applications de base, des solutions intégrées présentant un degré élevé d’automatisation ont été mises en œuvre; la compréhension des flux de données et de valeurs exige des connaissances spécialisées.

Pour les applications de base, des solutions intégrées dotées d’interfaces automatisées sont utilisées; les flux de données et de valeurs sont compréhensibles.

Pour les applications de base, différentes solutions individuelles dotées d’interfaces (entre lots,

«batch») sont utilisées;

les flux de données et de valeurs sont facilement compréhensibles.

Plusieurs solutions individuelles spécifiques aux fonctions et dotées d’interfaces (entre lots,

«batch») sont utilisées; les flux de données et de valeurs dans les applications et au niveau des interfaces sont documentés de manière compréhensible au moyen d’évaluations et de protocoles d’interface.

Erreurs de programme dans les applications de base

Les applications de base connaissent fréquemment des problèmes dont la résolution exige beaucoup de temps.

Les erreurs et les défaillances se répètent souvent.

Les erreurs dans les applications de base sont rares, mais leur résolution exige beaucoup de temps.

Les pannes et les défaillances se répètent rarement.

Les erreurs dans les applications de base sont rares et peuvent être résolues rapidement. Les erreurs et les défauts sont documentés

Les erreurs dans les applications de base sont très rares; les erreurs et les défauts sont résolus systématiquement, rapidement et durablement et ils sont documentés de manière compréhensible.

(14)

Exploitation IT

Ce domaine thématique permet d’évaluer la sécurité de l’exploitation des moyens informatiques ainsi que la situation en termes de personnel (suppléance / dépendance vis-à-vis de prestataires externes) dans le domaine de l’informatique.

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4

Sécurité de l’exploitation

des moyens informatiques Les moyens informatiques (serveur, clients, réseau et périphériques) connaissent très souvent des pannes et des défaillances; celles-ci ont une incidence sur l’ensemble des activités de l’entreprise.

Les moyens informatiques connaissent des pannes et des défaillances à répétition;

celles-ci ont une incidence sur l’ensemble des activités de l’entreprise.

Les moyens informatiques connaissent peu de pannes et de défaillances; celles-ci ont parfois une incidence sur les activités de l’entreprise.

Les moyens informatiques ne connaissent que rarement des pannes et des défaillances;

celles-ci n’ont une incidence que sur certaines activités de l’entreprise.

Suppléance au sein du

service informatique Les règles de suppléance au sein du service IT sont sommaires; l’absence de certaines personnes engendre des problèmes déjà au niveau de l’exploitation IT normale.

Des suppléances sont prévues pour les principales fonctions au sein du service IT, mais elles donnent rarement lieu à une formation; l’absence de certaines personnes a une incidence sur l’exploitation IT après quelques jours et la résolution des problèmes IT n’est pas possible.

Des suppléances existent pour les fonctions essentielles au sein du service IT; elles donnent lieu à une formation, mais elles ne sont pas documentées; l’exploitation IT est assurée, la résolution des problèmes IT est cependant difficile sans ces personnes.

Des suppléances existent pour les fonctions essentielles au sein du service IT; elles donnent lieu à une formation et il existe une documentation correspondante; l’exploitation IT et la résolution efficace des problèmes IT sont assurées.

Dépendance vis-à- vis de prestataires externes (y c. partenaires d’externalisation)

Pour l’exploitation IT, l’entreprise dépend largement du soutien extérieur; celui-ci est notamment indispensable en cas de problèmes.

L’exploitation IT normale est largement possible sans soutien extérieur; en revanche, les erreurs ou problèmes ne peuvent guère être résolus sans soutien extérieur.

L’exploitation IT normale est assurée sans soutien extérieur; en cas d’erreurs ou de problèmes, un soutien extérieur est parfois nécessaire.

L’exploitation normale et la résolution des problèmes sont assurées à tout moment sans soutien extérieur; celui-ci est uniquement nécessaire en cas de crise.

Audit indépendant de l’informatique (risque temporel)

Ce critère montre à quelle date l’utilisation de l’informatique dans l’entreprise a été évaluée pour la dernière fois par un expert indépendant.

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4

Audit indépendant de

l’informatique Aucun audit IT n’a encore été

effectué. Un audit IT a été effectué

pour la dernière fois il y a plus de cinq ans.

Un audit IT a été effectué pour la dernière fois il y a quelques années.

Un audit IT a été effectué au cours de l’exercice écoulé.

Comment remplir le questionnaire

Pour chacun des 16 critères, il convient de choisir parmi les quatre «réponses» celle qui correspond le mieux à la situation actuelle de l‘entreprise.

Il ne faut pas donner des évaluations «entre» les niveaux de maturité (1 – 2, 2 – 3 et 3 – 4), ceci ayant peu d’utilité. En cas

de doute, le niveau inférieur doit être sélectionné, car ceci réduit le risque d’audit.

(15)

13

Interprétation des résultats / Evaluation

L’interprétation du questionnaire s’effectue au moyen des niveaux de maturité. S’agissant de l’évaluation de la phase 1, un niveau de maturité ne correspond pas forcément à un degré de maturité technique ou organisationnel, mais à un facteur de risque potentiel. Par exemple, une entreprise dotée d’un degré d’innovation (question 2) de niveau 1 (c.-à-d. avec une adaptation très précoce aux nouvelles technologies IT) s’expose certainement à un risque plus élevé qu’avec un niveau 4 (qui correspond à une adaptation conservatrice et à des moyens IT standardisés et moins modernes).

Sur la base de leurs connaissances et de leurs expériences, les auteurs du «Guide d’analyse des risques informatiques» esti- ment qu’une classification dans les niveaux de maturité 4 et 3 indique des risques minimes. En revanche, une classification dans les niveaux de maturité 2 et 1 indique des risques importants à élevés.

Rapport

Pour le rapport concernant la phase 1, une solution efficace et facilement visualisable consiste à documenter l’évaluation (niveau) directement dans le questionnaire en attribuant la couleur voulue à la «réponse» sélectionnée (p. ex. 1 = rouge, 2

= jaune, 3 = vert clair et 4 = vert foncé).

(16)

Les résultats de la phase 1 peuvent ainsi être récapitulés sur une seule page. Etant donné que, avec ce type de représentation, les descriptions des quatre niveaux de maturité sont visibles, une comparaison rapide des conditions correspondant au niveau choisi avec celles des niveaux de maturité voisins (supérieurs/inférieurs) est également possible. A côté de la représentation des résultats en forme de tableau ci-dessus, un «graphique en toile d’araignée» permet aussi de déterminer le degré de dépendance de l’entreprise par rapport à l’informatique. Un exemple d’un tel graphique est donné ci-dessous pour une entreprise individuelle (à gauche) et pour quatre types d’entreprise différents (à droite):

Figure: Représentation des 16 critères Figure: Récapitulatif des 5 domaines thématiques

Recommandations quant à la poursuite de la procédure

Lorsqu’un ou plusieurs critères sont classés dans les niveaux de maturité 2 et 1 ou dans les couleurs jaune et rouge, les auteurs considèrent qu’il est opportun de déclencher la phase 2, c’est-à-dire un contrôle approfondi de l’utilisation de l’informatique.

Enfin, il appartient à l’auditeur, et à son «professional judgement», d’évaluer les résultats obtenus au cours de la phase 1 concernant les risques et les dépendances liés à l’utilisation de l’informatique du point de vue de leur importance pour l’audit des comptes annuels. A cet égard, il peut être judicieux de discuter des résultats et de la nécessité d’un contrôle approfondi de l’utilisation de l’informatique avec un auditeur IT expérimenté.

0 0.5

1 1.5

2 2.5

3 3.5

4 Stratégie et IT

Innovation IT Dépendance IT

SCI

Gestion des risques

Séparation des fonctions Suppléance Sensibilisation Logiciels comptables

Degré d’intégration de la comptabilité

Erreurs de programme

Sécurité de l’exploitation IT Suppléance IT Dépendance par rapport à l’extérieur

Risque temporel de l’audit IT

0.0 0.5 1.0 1.5 2.0 2.5

3.0Exploitation et IT

Organisation interne

et contrôle Applications IT

Risque temporel

Banque Fiduciaire Hôpital Industrie

Exploitation IT

Applications de base

(17)

15

Positionnement

La phase 2 correspond à un contrôle vaste et détaillé des forces et des faiblesses liées à l’utilisation de l’informatique.

Le traitement des questions/du questionnaire de la phase 2 peut s’effectuer tant dans le cadre de la planification stratégique de l’audit que dans celui de l’audit (intermédiaire) proprement dit.

Les résultats de la phase 2 peuvent servir à une évaluation finale des «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890, mais ils peuvent également justifier à l’aide de faits le besoin de réaliser un contrôle complet et/ou approfondi de l’utilisation de l’informatique dans son ensemble ou au niveau de domaines spécifiques.

Procédure et parties prenantes

Les contrôles lors de la phase 2 doivent être réalisés par un auditeur familiarisé avec les audits IT ou par un auditeur IT.

Ils comprennent, outre une inspection de l’infrastructure IT et la consultation des documents disponibles, des entretiens approfondis avec les représentants IT de l’entreprise.

Pour les contrôles «sur place», notamment le traitement du questionnaire, nous estimons le temps nécessaire à un jour;

à cet égard, l’étendue de l’utilisation de l’informatique et le nombre d’interlocuteurs concernés sont déterminants.

A l’issue de la phase 2, des affirmations fiables peuvent être énoncées quant aux risques IT et aux faiblesses concrètes.

Ceci permet de déterminer si un audit IT complet est opportun et dans quels domaines.

Questionnaire / Critères ( ➔ détails dans l’annexe 2)

Le questionnaire de la phase 2 comprend 20 domaines thématiques dotés de quatre points de contrôle en moyenne;

selon les auteurs du guide, il couvre intégralement les «contrôles IT généraux» mentionnés dans la Norme d’audit suisse NAS 890 «Vérification de l’existence du système de contrôle interne» et, dans certains domaines, il va même volontairement au-delà afin de réduire le risque d’audit.

Le questionnaire contient environ 90 critères (points de contrôle) concernant les domaines thématiques suivants:

• Documentation IT • Protection des accès

• Organisation IT • Sécurité IT

• Gouvernance IT • Sécurité physique

• Gestion des risques IT • Exploitation IT

• Conformité • Gestion des problèmes

• Gestion des projets IT • Sauvegarde des données

• Développement et modification de logiciels • Externalisation (le cas échéant)

• Evaluation d’applications IT • Comptabilité

• Directives d’utilisation • Contrôles d’application directs

• Formation des utilisateurs • Contrôles d’application secondaires

5 Phase 2: Contrôle relatif à l’utilisation de l’informatique

(18)

Pour une grande partie des domaines thématiques cités, il s’agit de contrôles IT généraux; certains domaines supplémentaires qui sont importants pour l’auditeur et permettent d’identifier plus précisément les faiblesses et les risques éventuels sont également contrôlés.

Comment remplir le questionnaire

Pour chacun des critères, il convient de choisir parmi les quatre «réponses» celle qui correspond le mieux à la situation actuelle de l’entreprise. L’évaluation (niveau) est donnée dans la colonne «Niveau» du questionnaire ou indiquée directement en cochant la «réponse» appropriée.

Pour l’évaluation et le rapport, il est utile de fournir des indications complémentaires dans la colonne «Constatation / Evaluation / Recommandation»; idéalement, celles-ci doivent être identifiées par un «C» pour constatation, un «E» pour évaluation et un «R» pour recommandation.

Il ne faut pas donner des évaluations «entre» les niveaux de maturité (1 – 2, 2 – 3 et 3 – 4); en cas de doute, les auteurs du guide recommandent de choisir le niveau inférieur (p. ex. 1 au lieu de 1 – 2) pour réduire le risque d’audit.

Si un critère n’est pas pertinent pour l’entreprise (p. ex. questions concernant l’externalisation), on peut indiquer «n.a.»

(non applicable) dans la colonne «Niveau» du questionnaire.

Interprétation des résultats / Evaluation

L’interprétation du questionnaire s’effectue au moyen des niveaux de maturité. Contrairement à la phase 1, ceux-ci correspondent plutôt à un degré de maturité technique ou organisationnel et pas forcément à un facteur de risque potentiel. Cependant, il existe incontestablement un rapport entre la maturité du processus et le risque en question.

Sur la base de leurs connaissances et de leurs expériences, les auteurs du «Guide d’analyse des risques informatiques»

estiment qu’une classification dans les niveaux de maturité 4 et 3 indique un degré de maturité satisfaisant et des risques

minimes. En revanche, une classification dans les niveaux de maturité 2 et 1 indique un degré de maturité insuffisant et des

risques importants à élevés.

(19)

17

Rapport

Au vu de l’étendue du questionnaire, nous proposons diverses approches pour la visualisation des résultats relatifs à la phase 2. Deux des variantes que nous avons testées à plusieurs reprises sont décrites ci-après.

Accent sur la représentation détaillée de la situation réelle

Il est possible d’établir un rapport détaillé en attribuant la couleur voulue à la réponse pour chaque critère ou à la colonne

«Niveau» (1 = rouge, 2 = jaune, 3 = vert clair et 4 = vert foncé).

Les résultats de la phase 2 peuvent ainsi être visualisés dans leur globalité sur environ dix pages (format A4), avec les forces et les faiblesses pour chaque critère. Une évaluation du «contenu» est donnée au moyen des descriptions relatives aux différents niveaux et via la colonne «Constatation / Evaluation / Recommandation».

Accent sur la représentation des mesures à prendre

Lorsqu’une opinion sur les «mesures à prendre» doit être émise, l’étendue du rapport peut être réduite en «éliminant»

tous les critères dotés d’évaluations de niveaux 3 et 4 (contrôle satisfaisant / risque minime) et «n.a.» (non applicable).

Selon la situation, les faiblesses existantes, et donc les mesures à prendre, peuvent ainsi être récapitulées sur quelques pages seulement (format A4).

Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation

Documentation IT

Aperçu de l'infrastructure IT

Il n'existe pas d'aperçu de

l'infrastructure IT. Il existe un aperçu ancien (remontant à plus d'une année) de l'infrastructure IT.

Il existe un aperçu actuel des principaux composants de l'infrastructure IT (systèmes et gestion de réseau).

Les processus d'acquisition, d'installation et de gestion des changements n'entraînent pas obligatoi- rement une actualisation de cet aperçu.

Il existe un aperçu actuel de l'ensemble de l'infrastructure IT (systèmes et gestion de réseau). Les processus d'acquisition, d'installation et de gestion des changements comprennent l'actualisation obligatoire de cet aperçu.

Inventaire

du matériel Il n'existe pas d'inventaire du

matériel. Il existe un inventaire ancien

(remontant à plus d'une année) du matériel.

Un inventaire du matériel est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas l'actualisation obligatoire de cet inventaire.

Un inventaire complet du matériel est en cours de réalisation. Les processus d'acquisition et d'installation comprennent l'actualisation obligatoire de cet inventaire ainsi que l'adaptation/la conclusion de contrats de maintenance éventuels.

Inventaire des

logiciels Il n'existe pas d'inventaire

des logiciels. Il existe un inventaire ancien (remontant à plus d'une année) des logiciels.

Un inventaire des logiciels (également pour le contrôle des licences) est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas l'actualisation obligatoire de cet inventaire.

Un inventaire complet des logiciels (également pour le contrôle des licences) est en cours de réalisation. Les processus d'acquisition et d'installation comprennent l'actualisation obligatoire de cet inventaire ainsi que la clarification des éventuelles questions relatives à l'octroi de licences d'installations et de mises à jour.

Contrats et contrats de prestation de services

Il existe peu de contrats entre le domaine IT et des tiers, même si des presta- tions sont fournies.

Il existe un aperçu/récapitu- latif des contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires); celui-ci est cependant incomplet et pas actuel.

Il existe un aperçu/récapi- tulatif de tous les contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires).

Il existe un aperçu/récapi- tulatif de tous les contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires). Celui-ci est géré centralement, tenu à jour et contient tous les contrats et documents connexes tels que les SLA, etc.

(20)

Représentation graphique de la situation réelle

Pour la pratique, les auteurs du guide considèrent qu’il est utile de faire un résumé des évaluations par domaine thématique et, par exemple, de les représenter dans un diagramme circulaire. En indiquant les couleurs voulues, la situation réelle (ici en vert) et les mesures à prendre «potentielles» (ici en rouge) peuvent être très bien visualisées.

0 0.5

1 1.5

2 2.5

3 3.5

4 Documentation IT

Organisation IT Gouvernance IT

Gestion des risques IT Conformité

Gestion de projet IT

Développement de logiciels

Evaluation d’applications IT Application comptable

Contrôle d’application direct

Directives d’utilisation Contrôle d’application secondaire

Formation des utilisateurs Protection des accès

Sécurité IT Sécurité physique Exploitation IT Gestion des problèmes Sauvegarde des données

Externalisation

Rapport succinct complémentaire

Les auteurs du guide considèrent qu’il est utile de récapituler les principales forces et faiblesses ainsi que les principales recommandations d’optimisation de la situation dans un rapport succinct destiné au management, au conseil d’administration et à l’auditeur.

Le rapport succinct constitue un complément précieux à la représentation graphique de la situation réelle ci-dessus et permet de réaliser une évaluation globale de la situation actuelle et des mesures à prendre et, le cas échéant, de justifier le besoin d’exécuter un audit IT approfondi.

Recommandations quant à la poursuite de la procédure

Lorsqu’une grande partie des critères sont classés dans les niveaux de maturité 2 et 1, les auteurs du guide considèrent qu’il

est opportun d’exécuter un audit IT complet ou un audit approfondi de l’utilisation de l’informatique dans son ensemble

ou au niveau de domaines spécifiques.

(21)

19

Considérations initiales

Le contenu des phases 1 et 2 peut, notamment lorsque les contrôles des deux phases sont effectués simultanément et par le même auditeur, être récapitulé à peu de frais dans un IT-Check.

En peu de temps (souvent un seul jour «sur place» suffit), il est possible:

• de déterminer l’importance que revêt l’informatique pour l’entreprise et les risques liés à son utilisation;

• d’identifier les forces et les faiblesses liées à l’organisation et aux processus IT et d’évaluer ensuite l’«utilité» de l’informatique en général ainsi que les «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890;

• de documenter et d’évaluer sommairement les applications de base, y c. les principaux flux de valeurs et de données (interfaces IT) ainsi que les interlocuteurs concernés par leur utilisation, leur maintenance et leur exploitation.

Procédure

Préparation

• Envoyer au préalable le questionnaire de la phase 1 au client et demander à celui-ci de procéder à une évaluation des risques (auto-évaluation) de son point de vue, laquelle sera ensuite discutée en commun lors des contrôles «sur place».

• Envoyer également au préalable le questionnaire de la phase 2 au client pour que celui-ci puisse préparer l'évaluation des contrôles «sur place» (p. ex. mise à disposition de documents ou implication d’autres collaborateurs).

Exécution

1. Réaliser un entretien d’ouverture

Déterminer les bases de l’organisation IT et de l’utilisation de l’informatique 2. Effectuer un tour d’inspection

Se faire une idée de l’infrastructure IT 3. Discuter du questionnaire de la phase 1

Déterminer l’importance que revêt l’informatique pour la comptabilité et l’entreprise et examiner l’évaluation des risques faite par le client

4. Etudier le questionnaire de la phase 2

Identifier les forces et les faiblesses liées à l’organisation et aux processus IT; évaluer la «maturité» de l’informatique 5. Contrôler les applications de base

Se faire une idée des applications de base ainsi que des principaux flux de valeurs et de données (interfaces); catégoriser les applications financières (logiciels standard, logiciels standard adaptés ou logiciels individuels); identifier les interlocuteurs concernés par leur utilisation, leur maintenance et leur exploitation

6. Bref feed-back (oral)

Remarque: le contrôle portant sur les applications de base (étape 5) est une étape de travail à part entière qui n’est pas traitée de manière approfondie dans le présent guide. Elle est décrite en détail dans le «Guide d’audit des applications informatiques».

6 L’IT-Check comme «combinaison» des phases 1 et 2

(22)

Rapport / Rapport succinct

• Management Summary avec principales constatations et mesures à prendre

• Aperçu de l’organisation IT, de l’utilisation de l’informatique et des applications de base

• Résultats (constatation, évaluation et éventuellement recommandation) sur l’organisation et les processus IT

• Résultats (constatation, évaluation et éventuellement recommandation) sur les applications de base

• Résultats de l’auto-évaluation (questionnaire de la phase 1)

Dans la pratique, il s’avère utile d’établir une représentation distincte des résultats par domaine thématique, comme le montre l’exemple ci-après. Une représentation détaillée de ce type ne peut cependant pas être le fruit d’une évaluation réalisée sur une journée: pour un rapport succinct, il faut généralement plus de temps pour contrôler les informations et beaucoup plus encore pour le rapport lui-même. L’auditeur obtient toutefois une base plus précise pour la planification stratégique de l’audit, et le client bénéficie clairement d’une importante valeur ajoutée.

Figure: Présentation détaillée des résultats sous forme de texte (exemple)

Avantages pour l’auditeur

S’agissant des mandats/clients soumis à un contrôle ordinaire:

• l’évaluation des risques IT fait partie de la planification stratégique de l’audit;

• les «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890 peuvent être évalués définitivement;

• un IT-Check fournit des informations fiables et vérifiables pour la détermination des domaines d’audit à intégrer dans un audit IT complet – ou tout du moins des arguments clairs justifiant leur suppression ou leur report.

4.14 Sauvegarde des données

Constatations

Il existe un concept de sauvegarde datant de janvier 200x; celui-ci n'a pas été approuvé formellement. Des sauvegardes complètes sont effectuées les jours ouvrables, 4 bandes étant disponibles le vendredi (semaine 1 – 4). Aucun test de restauration visant à vériﬁer la lisibilité n'est réalisé. Les bandes de sauvegarde ne sont pas conservées à l'extérieur de l'entreprise, mais dans un tiroir du responsable IT concerné. Il n'existe pas de plan d'urgence IT.

Degré de maturité déterminé Concept de

sauvegarde Processus de sauvegarde Test de restauration Plan d'urgence IT Transfert des données

Un concept de sauvegarde est documenté et généralement utilisé; il n'a toutefois jamais été approuvé formellement.

Des sauvegardes quotidiennes sont effectuées, mais leur intégralité n'est pas contrôlée.

Aucun test systématique n'est réalisé pour récupérer et relire les sauvegardes.

Peu de réflexions sont engagées quant à un plan d'urgence IT.

Aucune sauvegarde suffisante des données n'est assurée à l'extérieur de l'entreprise.

Mesures à prendre

• Approbation formelle du concept de sauvegarde

• Réalisation de tests de restauration réguliers

• Conservation des bandes en dehors de l'entreprise

• Déﬁnition d'un plan d'urgence IT

Risques

• Restauration incomplète des données en cas d'incident

• Restauration des données en dehors des délais exigés

• Perte de données en cas de catastrophe

• Mise en danger de la poursuite de l'exploitation lT

(23)

21

Situation initiale

A l’issue de la phase 2, des affirmations fiables peuvent être énoncées et justifiées quant au degré de maturité technique et organisationnel ainsi qu’aux risques IT.

Sur cette base, l’auditeur peut, de préférence en accord avec un auditeur IT expérimenté, décider si et pour quels domaines un audit IT approfondi doit être effectué, mais également si des domaines connexes, et lesquels, doivent être vérifiés en détail dans le cadre de contrôles approfondis ou de l’audit intermédiaire.

Domaines d’audit possibles

Sur la base de leurs connaissances et de leurs expériences, les auteurs du guide voient principalement les deux domaines suivants pour un audit IT approfondi faisant suite à la phase 2:

Domaine d’audit 1: application informatique et SCI lors de leur utilisation

Objectifs de l’audit

a) Evaluation de l’application IT sous les aspects suivants:

- présence des fonctions de traitement nécessaires - exactitude des règles de traitement programmées - possibilités de différenciation au moyen de droits d’accès

- étendue et efficacité du système de contrôle interne (SCI) basé sur des logiciels, c’est-à-dire des contrôles programmés - documentation (intégralité/clarté et conformité avec les programmes)

- adéquation et degré de développement des résultats des transactions du point de vue des dispositions légales en matière de comptabilité et de conservation

- méthode d’audit, c’est-à-dire preuve des transactions importantes du point de vue de la comptabilité depuis leur origine jusqu’à la présentation des comptes (progressif) et inversement (rétrograde)

b) Evaluation du SCI lors de l’utilisation de l’application IT, de la documentation d’utilisation, de l’installation («customizing»), de la maintenance (modifications du programme) et, le cas échéant, évaluation des «contrôles IT généraux» lors de leur exploitation.

Méthodes

«Guide d’audit des applications informatiques» de la Chambre fiduciaire et listes de contrôle d’origines diverses pour le contrôle du système de contrôle interne. Le choix de l’application IT se base sur l’étape 5 d’un IT-Check (voir le chapitre 6), c’est-à-dire le contrôle de toutes les applications de base.

Domaine d’audit 2: organisation et processus IT

Objectif de l’audit

Contrôle approfondi de l’organisation, des processus et des contrôles IT. Ceci permet d’approfondir et d’élargir des domaines thématiques importants issus de la phase 2 et couvre intégralement les «contrôles IT généraux» conformément à la Norme d’audit suisse «Vérification de l’existence du système de contrôle interne» (NAS 890).

7 Indications concernant les audits IT approfondis

(24)

Base méthodologique / Dossiers de travail

La norme C

obi

T (Control Objectives for Information and related Technologies) de l’ISACA ( ➔ www.isaca.ch), acceptée dans le monde entier et largement utilisée, constitue une base de travail éprouvée. Le référentiel C

obi

T classe les activités et les responsabilités IT au sein d’un modèle de processus générique dans les quatre domaines suivants: «Planification et organisation», «Acquisition et mise en place», «Distribution et support» et «Surveillance et évaluation».

C

obi

T contient une approche et un langage commun, valable pour toute l’entreprise, pour l’examen et la gestion des activités IT. L’introduction d’une approche opérationnelle et d’un langage commun pour toutes les personnes concernées est l’une des étapes les plus importantes visant à mettre en place une bonne gouvernance. Cette approche aide les propriétaires des processus fonctionnels et permet de définir les tâches et les responsabilités.

C

obi

T contient en outre un référentiel pour mesurer et évaluer la performance IT, communiquer avec les prestataires de services et intégrer des meilleures pratiques.

Planification de l’audit

Les expériences faites par les auteurs du guide montrent que les donneurs d’ordre éventuels (auditeur / client) n’ont souvent qu’une idée imprécise des objectifs et des possibilités, mais aussi de la durée et de l’utilité, d’un «audit IT approfondi».

Pour impliquer un auditeur IT spécialisé de manière efficace et ciblée, la formulation du mandat d’audit est très importante.

Selon les auteurs du guide, il est donc judicieux d’impliquer l’auditeur IT et le client.

Le mandat d’audit confié par l’auditeur à l’auditeur IT doit porter au minimum sur les points suivants:

• objectifs supérieurs / conditions cadres

• contenu et étendue détaillés de l’audit / délimitation

• base méthodologique / dossiers de travail

• interlocuteurs et sources d‘information éventuels

• rapport, y c. structure, contenu, étendue et destinataires du rapport

Audit

Au vu des grandes différences d’un audit IT approfondi en ce qui concerne le domaine d’audit ainsi que le contenu et l’étendue de l’audit, nous renonçons à fournir des indications détaillées sur l’audit.

A titre indicatif, pour un audit IT approfondi réalisé dans une PME, il faut prévoir entre trois et dix jours pour les contrôles

«sur place» et entre deux et cinq jours supplémentaires pour le rapport.

(25)

23

Rapport

Le rapport se base en principe sur ce qui a été convenu lors de la planification de l’audit (voir ci-dessus). Les principaux points sont entre autres:

• La structure, l’étendue et le contenu dépendent des objectifs et du public cible.

• Le rapport doit être clairement structuré et axé sur les destinataires:

- Management Summary avec principales constatations et recommandations;

- détails (constatation, évaluation et recommandation) à l’attention du management sous forme verbale;

- détails avec constatation, évaluation et recommandation (y c. ordre de priorité du point de vue de l’auditeur) à l’attention des responsables techniques sous forme de tableau;

- récapitulatif des recommandations (selon l’ordre de priorité) et, le cas échéant, prise de position de l’audité ainsi que délai et responsables de la mise en œuvre de la recommandation.

• Le rapport doit préciser clairement la situation actuelle et les mesures à prendre.

D’après notre expérience, il est fortement recommandé de discuter du projet de rapport avec la personne auditée et, le cas échéant, le management. Ceci permet de clarifier les incertitudes et les malentendus éventuels avant d’établir et d’envoyer le rapport définitif.

Un tel rapport ressemble au rapport succinct établi pour un IT-Check (voir page 20), mais il est généralement beaucoup plus

concret sur certains points. Sont notamment concernés l’ordre de priorité des recommandations et la prise de position de

l’audité (y c. délai et responsabilités pour la mise en œuvre).

(26)

Malgré l’existence et l’utilisation d’un certain nombre de supports (approches, questionnaires, référentiel C

^obi

T, listes de contrôle, etc.), le «professional judgement» de l’auditeur est indispensable pour obtenir des résultats répondant aux exigences spécifiques à l’entreprise, aux processus et aux risques.

Une discussion approfondie entre l’auditeur et l’auditeur IT s’impose pour évaluer les résultats des audits et, le cas échéant, déterminer d’autres opérations d’audit nécessaires. Le présent «Guide d’analyse des risques informatiques pour les auditeurs de PME» doit contribuer à améliorer la compréhension des domaines IT spécifiques.

8 Conclusion

(27)

25

Annexes

Annexe 1 Questionnaire Phase I

Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Maturité

Exploitation et IT

Stratégie de l’entreprise et utilisation de l’informatique

La stratégie de l’entreprise repose principalement sur l’utilisation d’Internet et des nouvelles technologies ainsi que sur l’échange actif d’informations via des réseaux de données.

La stratégie de l’entreprise repose en partie sur l’utilisation d’Internet et des nouvelles technologies; les processus importants de l’entreprise se basent sur l’échange d’informations via des réseaux de données.

La stratégie de l’entreprise dépend peu des nouvelles technologies, mais les processus importants de l’entreprise utilisent déjà ces technologies.

La stratégie de l’entreprise ne dépend pas des nouvelles technologies (p. ex. Internet ou e-commerce).

Degré

d’innovation dans l’utilisation de l’informatique

L’entreprise utilise une infrastructure IT moderne et complexe et s’adapte clairement aux nouvelles technologies avant l’ensemble du secteur.

L’entreprise utilise une infrastructure IT complexe et s’adapte aux nouvelles technologies sans retard.

L’entreprise utilise une infrastructure IT étendue, comprenant dans une large mesure des composants standard, et s’adapte aux nouvelles technologies avec du retard.

L’entreprise utilise une infrastructure IT simple, comprenant dans une large mesure des composants standard; l’infrastructure IT est plutôt en retard par rapport aux développements technologiques.

Dépendance par rapport à la disponibilité des moyens informatiques

DiLa disponibilité des moyens informatiques est un facteur critique pour l’exploitation (activités de front-office et processus primaires);

le temps de défaillance acceptable est inférieur à quatre heures.

La disponibilité des moyens informatiques est importante pour l’exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre quatre heures et deux jours.

La disponibilité des moyens informatiques est parfois importante pour l’exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre deux jours et une semaine.

La disponibilité des moyens informatiques n’est pas critique pour l’exploitation (activités de front-office) et les processus primaires internes; une défaillance supérieure à une semaine semble acceptable.

Organisation interne et contrôle

Gestion des

risques Il n’y a pas de gestion des risques identifiable; des mesures ad hoc sont mises en œuvre pour réduire les risques.

Il y a une gestion des risques ponctuelle, spécifique aux applications et partiellement documentée; les mesures de réduction des risques en découlant ne sont pas (facilement) identifiables.

Il y a une gestion des risques formalisée au niveau de toute l’entreprise; elle est documentée et actualisée chaque année et les risques sont clairement réduits.

La gestion des risques est complétée par une auto- évaluation des contrôles mis en place.

Système de

contrôle interne Un système de contrôle interne (SCI) est difficilement identifiable ou inexistant.

Il y a un SCI ponctuel, spécifique aux domaines d’activité; le niveau de documentation et d’actualisation est toutefois peu clair.

il est documenté et actualisé chaque année. Le SCI est complété par une auto- évaluation des contrôles mis en place.

Sensibilisation à la sécurité de l’information

Les collaborateurs ne sont pas informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l’information.

Les collaborateurs sont informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l’information.

Les collaborateurs sont formés systématiquement et le respect des exigences internes et externes en matière de sécurité de l’information est contrôlé régulièrement.

Séparation des

fonctions Il y a uniquement une séparation des fonctions sommaire et informelle; il existe (également eu égard à l’informatique) des fonctions couvrant plusieurs services.

Il y a une séparation des fonctions entre l’informatique et les domaines d’activité; les fonctions au sein des services spécialisés ne sont parfois pas séparées.

Au sein des domaines d’activité, une séparation fonctionnelle des fonctions est systématiquement assurée; celle-ci est documentée dans les descriptions des tâches et contrôlée en continu.

Suppléance et savoir-faire en matière d’applications au sein du service de comptabilité

Seule une suppléance sommaire est assurée au sein de l’entreprise; l’absence de certaines personnes engendre des problèmes déjà au niveau des activités quotidiennes habituelles.

Des suppléances sont prévues pour les fonctions importantes, mais la formation est quasi inexistante; l’absence de certaines personnes a une incidence sur les activités quotidiennes habituelles après quelques jours; la résolution des problèmes et des incidents n’est pas possible en cas de défaillance.

Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; il y a une documentation correspondante; les activités quotidiennes habituelles et la résolution efficace des problèmes sont assurées.