Audit II Audit et contrôle en milieu informatisé

Séance 4. Capsule N°1

Professeur : Abdelhaq El Bekkali,

Ph.D, CPA (Expert-comptable)

e.isiam.ma
 Le processus TI

Traite d’objectifs de contrôle vis-à-vis de domaines spécifiques comme,

l’organisation, la mise en œuvre, le support et la surveillance

Dans sa version 4.1, Cobit présente 34 processus répartis entre 4

domaines

Chacun des 34 processus est destiné à fournir une information devant

répondre aux besoins d’affaires selon les critères d’efficacité,
d’efficience, de confidentialité, d’intégrité, de disponibilité, de
conformité et de fiabilité.

2
Pour chacun des 34 processus, Cobit détermine 4 rôles présentés sous
l’acronyme RACI :

 Responsible (personne chargée de la réalisation de tâches reliées

à un processus donné),

 Accountable (personne qui fixe les priorités et les directives),

 Consulted (personne devant être consultée),

 et Informed (personne devant être informée).

3
 Le cube Cobit

4
Cobit détermine dans le processus TI:

 4 domaines: regroupement naturel de processus correspondant

souvent à un domaine de responsabilité organisationnel

 34 processus: série d’activités et de tâches groupées et qui

constituent les objectifs de contrôle général

 220 activités: tâches nécessaires à l’obtention d’un résultat

mesurable et qui forment les objectifs des contrôles détaillés.

5
Le concept de « domaine » est important dans l’architecture de Cobit,
car il définit une répartition logique vis-à-vis des systèmes
d’information

Les domaines se définissent comme suit dans Cobit 4.1:

 Planification et Organisation (PO)

 Acquisition et Implémentation (AI)

 Distribution et Support (DS)

 Surveillance et Évaluation (SE).

6
 Planification et Organisation (PO)

Ce domaine recouvre, la stratégie et la vision TI permettant de faire en

sorte que les TI contribuent à la réalisation des objectifs de
l’organisation

Cette stratégie doit être planifiée, communiquée et gérée

adéquatement.

7
 Le domaine PO, regroupe les 10 processus suivants:

PO1: définir un plan informatique stratégique

PO2: définir l’architecture de l’information
PO3: déterminer l’orientation technologique
PO4: Définir les processus, l’organisation et les relations de travail
PO5: gérer l’investissement informatique
PO6: Faire connaître les buts et les orientations du management
PO7: gérer les ressources humaines de l’informatique
PO8: gérer la qualité
PO9: évaluer et gérer les risques
PO10: gérer les projets.

8
Application (des exemples)

PO1.2 Alignement métiers-informatique

Objectif de contrôle:

« Instaurer des processus de formation bi-directionnelle et

d’engagement réciproque dans le plan stratégique pour arriver à un
alignement et une intégration de l’informatique et des métiers.
Trouver un compromis entre les impératifs métiers et ceux de
l’informatique de façon à ce que les priorités fassent l’objet d’un
agrément mutuel. »

9
PO7.4 Formation

Objectif de contrôle:

« Bien orienter les employés des SI à l’embauche et leur dispenser la

formation permanente nécessaire pour tenir à jour leurs
connaissances, compétences, capacités et leur sensibilisation au
contrôle interne et à la sécurité au niveau nécessaire pour permettre à
l’entreprise d’atteindre ses objectifs.

10
 Acquisition et Implémentation (AI)

Ce domaine recouvre la stratégie TI qui doit identifier, développer ou

acquérir les solutions TI et les intégrer adéquatement aux différents
processus d’affaires. La stratégie TI doit aussi s’assurer que les
changements et la maintenance des systèmes sont opérés en
concordance avec les objectifs des différents processus
d’affaires.

11
Le domaine AI porte sur les points suivants:

 Le développement ou l’acquisition de nouvelles solutions TI

répondent adéquatement aux besoins des processus d’affaires;

 Les nouveaux systèmes acquis ou développés fonctionnent

correctement;

 Les changements réalisés ne remettent pas en cause le

fonctionnement général du système.

12
 Le domaine AI, regroupe les 7 processus suivants:

AI1: trouver des solutions informatiques

AI2: acquérir des applications et en assurer la maintenance
AI3: acquérir une infrastructure technologique et en assurer la
maintenance
AI4: Faciliter le fonctionnement et l’utilisation
AI5: acquérir les ressources informatiques
AI6: gérer les changements
AI7: Installer et valider les solutions et les modifications.

13
Exemple

AI1 Trouver des solutions informatiques

« Le besoin d’une nouvelle application ou fonction impose une analyse avant

achat ou création pour s’assurer que les exigences des métiers seront
satisfaites grâce à une approche efficace et efficiente. Ce processus recouvre la
définition des besoins, la prise en compte de sources alternatives, l’analyse de
la faisabilité technique et économique, l’analyse des risques et du rapport
coûts/bénéfices, et la décision finale qui tranchera entre faire ou acheter.
Toutes ces étapes permettent aux entreprises de minimiser les coûts d’achat et
de mise en place de solutions et de s’assurer que celles-ci permettront à
l’entreprise d’atteindre ses objectifs. »

14
 AI1.1 Définition et actualisation des exigences métiers, techniques et
fonctionnelles

Objectif de contrôle:

« Identifier, classer par priorités et agréer les exigences métiers,

techniques et fonctionnelles, qui couvrent l’étendue complète de
toutes les initiatives requises pour obtenir les résultats escomptés du
programme d’investissement informatique. »

15
 Distribution et support (DS)

Ce domaine recouvre la fourniture des services informatiques, la

sécurité et la continuité, le support aux utilisateurs

Ce domaine interpelle l’organisation au niveau des points suivants:

 La rentabilité dans l’utilisation des systèmes;

 La sécurité de l’information (intégrité, confidentialité et

disponibilité).

16
 Le domaine DS, regroupe les 13 processus suivants:

DS1: définir et gérer des niveaux de service

DS2: gérer des services tiers
DS3: gérer la performance et la capacité
DS4: assurer un service continu
DS5: assurer la sécurité des systèmes
DS6: identifier et imputer les coûts
DS7: instruire et former les utilisateurs
DS8: gérer le service d’assistance clients les incidents
DS9: gérer la configuration
DS10: gérer les problèmes
DS11: gérer les données
DS12: gérer l’environnement physique
DS13: gérer l’exploitation.

17
Exemple

DS5.5 Tests de sécurité, vigilance et surveillance

Objectif de contrôle:

« Tester et surveiller de façon proactive la mise en place de la

sécurité informatique. Pour s’assurer que la sécurité informatique
se maintient au niveau convenu il faut revoir et renouveler en
temps voulu sa validation. Une fonction de surveillance des
identifications doit permettre une prévention /détection rapide
suivie d’un rapport en temps voulu des activités
inhabituelles/anormales qu’il peut être nécessaire de traiter. »

18
 Surveillance et Évaluation (SE)
Ce domaine recouvre l’évaluation et la surveillance de la qualité et de la
conformité des processus informatiques par rapport à des critères préétablies

Ce domaine interpelle l’organisation au niveau des points suivants:

 La surveillance continue de la performance de l’informatique et de

la correspondance de cette performance aux objectifs des
différents processus d’affaires;

 L’efficacité et l’efficience des contrôles;

 Le suivi et la production de rapports sur les contrôles, les risques et

la performance.

19
 Le domaine SE, regroupe les 4 processus suivants:

SE1 Surveiller et évaluer la performance des SI

SE2 Surveiller et évaluer le contrôle interne
SE3 S’assurer de la conformité aux obligations externes
SE4 Mettre en place une gouvernance des SI.

20
Exemple

SE2.6 Contrôle interne des tiers

Objectif de contrôle

« Évaluer la situation des contrôles internes des fournisseurs de

services externes. Confirmer que les fournisseurs de services externes
se conforment aux exigences légales et réglementaires, ainsi qu’à leurs
obligations contractuelles. »

21
 Objectifs de l’entreprise
Gouvernance des Technologies de l’Information
ME1 Monitor and evaluate IT performance. PO1 Define a strategic IT plan.
ME2 Monitor and evaluate internal control. PO2 Define the information architecture.
ME3 Ensure regulatory compliance. PO3 Determine technological direction.
ME4 Provide IT governance. PO4 Define the IT processes, organisation and relationships.
PO5 Manage the IT investment.
PO6 Communicate management aims and direction.
PO7 Manage IT human resources.
PO8 Manage quality.
INFORMATION PO9 Assess and manage IT risks.
• Effectiveness PO10 Manage projects.
• Efficiency
• Confidentiality
• Integrity
• Availability
• Compliance
• Reliability
MONITOR AND PLAN AND
COBIT 4.1

EVALUATE ORGANISE
IT RESSOURCES
• Applications
• Information
• Infrastructure
• People

ACQUIRE AND
DS1 Define and manage service levels.
DS2 Manage third-party services.
DELIVER AND IMPLEMENT
DS3 Manage performance and capacity. SUPPORT
DS4 Ensure continuous service.
DS5 Ensure systems security. AI1 Identify automated solutions.
DS6 Identify and allocate costs. AI2 Acquire and maintain application software.
DS7 Educate and train users. AI3 Acquire and maintain technology infrastructure.
DS8 Manage service desk and incidents. AI4 Enable operation and use.
DS9 Manage the configuration. AI5 Procure IT resources.
DS10 Manage problems. AI6 Manage changes.
DS11 Manage data. AI7 Install and accredit solutions and changes.
DS12 Manage the physical environment.
DS13 Manage operations.

22
 Le modèle de maturité de Cobit
Pour contrôler efficacement l'infrastructure du système d'information, les
managers se posent souvent le genre de questions suivantes:

 “Jusqu'où devons-nous aller, et le coût est-il justifié par le bénéfice ?”

 “Quels sont les standards internationalement reconnus, et comment sommes-

nous positionnés par rapport à eux ?”

 “Sur le marché, quelles pratiques sont-elles considérées comme les meilleures,

et comment sommes-nous positionnés par rapport à elles ?”

Pour pouvoir répondre à ces question, le référentiel Cobit offre un modèle de

maturité pour chacun des 34 processus TI.

23
Le modèle de maturité de Cobit permet au propriétaire du processus,
de déterminer le niveau d'adhésion de ce processus aux objectifs de
contrôle, soit sous la forme d'une auto-évaluation, soit en ayant
recours à une évaluation externe

L’évaluation des processus TI sur la base du modèle de maturité de

Cobit consiste pour l’organisation de se situer elle-même sur une
échelle graduée de 0 à 5 (d'Inexistant à Optimisé)

Cette approche est basée sur le Modèle de Maturité (CMMI)

développé par le Software Engineering Institute (Etats-Unis), pour
le développement de logiciels.

24
Modèle de maturité

25
En s’appuyant sur le modèle de maturité, la direction peut faire
apparaître, pour chacun des 34 processus TI du CobiT, :

 l'état actuel de l‘organisation (où elle se situe actuellement);

 l'état actuel des meilleures pratiques du marché (comparaison);

 l'état actuel des standards internationaux (autre comparaison);

 la stratégie de l’organisation en matière de progrès (où

l‘organisation souhaite se situer?).

26
 Modèle général de maturité

 Niveau 0 (Inexistant): Absence totale de processus identifiables.

L‘organisation n'a même pas pris conscience qu'il s'agissait d'un
problème à étudier

 Niveau 1 (Initialisé): l‘organisation a pris conscience de l'existence

du problème et de la nécessité de l'étudier. Il n'existe toutefois
aucun processus standardisé, mais des approches dans ce sens
tendent à être appliquées individuellement ou au cas par cas.
L'approche globale du management n'est pas organisée.

27
 Niveau 2 (Reproductible): Des processus se sont développés
jusqu'au stade où des personnes différentes exécutant la même
tâche utilisent des procédures similaires. Il n'y a pas de formation
formelle ou de communication des procédures standard, et la
responsabilité est laissée à l'individu. On se repose beaucoup sur
les connaissances individuelles, d'où une probabilité d'erreurs

28
 Niveau 3 (Défini): Des procédures ont été standardisées,
documentées et communiquées via des séances de formation.
Toutefois, leur utilisation est laissée à l'initiative de chacun, et il est
probable que des déviations seront constatées. Concernant les
procédures elles-mêmes, elles ne sont pas sophistiquées, mais
formalisent des pratiques existantes.

29
 Niveau 4 (Géré): Il est possible de contrôler et de mesurer la
conformité aux procédures et d'agir lorsque des processus
semblent ne pas fonctionner correctement. Les processus sont en
constante amélioration et correspondent à une bonne pratique.
L'automatisation et l'utilisation d'outils s'effectuent d'une manière
limitée ou partielle

30
 Niveau 5 (Optimisé): Les processus ont atteint le niveau des
meilleures pratiques, suite à une amélioration constante et à la
comparaison avec d'autres organisations. L'informatique est utilisée
comme moyen intégré d'automatiser les flux de travaux, offrant des
outils qui permettent d'améliorer la qualité et l'efficacité et de
rendre l‘organisation rapidement adaptable.

31
Exemple. Maturité du processus DS5 Assurer la sécurité du
système

Niveau 0 Inexistant: L’entreprise ne reconnaît pas le besoin de sécurité

informatique. Les responsabilités opérationnelles et finales de la
sécurité ne sont pas attribuées. On n'a pas mis en place de mesures
pour gérer la sécurité informatique. Il n'y a pas de rapports sur cette
question, ni de processus pour réagir aux atteintes à la sécurité
informatique. Il y a une absence totale de processus reconnaissable
d'administration de la sécurité des systèmes.

32
 Niveau 1 Initialisé, au cas par cas: L’entreprise reconnaît le besoin
de sécurité informatique. La sensibilisation au besoin de sécurité
est principalement une affaire individuelle. On réagit aux
circonstances. La sécurité informatique ne fait pas l’objet de
mesures. Chacun désigne quelqu'un d'autre lorsque des atteintes à
la sécurité sont détectées, parce que les responsabilités ne sont pas
clairement définies. On ne peut pas prévoir quelles réponses
seront données aux incidents de sécurité.

33
 Niveau 2 Reproductible, mais intuitif: Les responsabilités
opérationnelles et finales de la sécurité des SI sont confiées à un
coordinateur bien que son autorité soit limitée. La sensibilisation
au besoin de sécurité est fragmentaire et limitée. Bien que les
systèmes produisent des informations relatives à la sécurité, on ne
les analyse pas. Les services fournis par des tiers ne répondent pas
toujours aux besoins de sécurité spécifiques de l’entreprise. On
développe des politiques de sécurité, mais les compétences et les
outils sont inadéquats. Les rapports sur la sécurité sont incomplets,
trompeurs ou sans pertinence. Il existe une formation à la sécurité,
mais elle reste avant tout une initiative individuelle. La sécurité
informatique est considérée surtout comme de la responsabilité et
du domaine de l’informatique, et les métiers ne voient pas qu’elle
fait partie du sien.

34
 Niveau 3: Défini: Le management fait la promotion de la sécurité et
le personnel commence à y être sensibilisé. Les procédures de
sécurité informatique sont définies et alignées sur la politique de
sécurité des SI. Les responsabilités dans ce domaine sont attribuées
et comprises, mais pas systématiquement exercées. Il existe un plan
de sécurité des SI et des solutions élaborées à partir de l’analyse des
risques. Les rapports sur la sécurité ne sont pas clairement axés sur
les métiers. On fait des tests de sécurité (ex. tests d’intrusion) au
cas par cas. La formation à la sécurité est accessible au personnel
informatique et des métiers, mais elle n’est gérée et planifiée que
de façon informelle.

35
Niveau 4: Géré et mesurable: Les responsabilités de la sécurité des SI sont
clairement attribuées, gérées et exercées. On analyse régulièrement les
risques informatiques et leurs conséquences. On complète les politiques et
les procédures de sécurité par des principes de base spécifiques à la
sécurité. On rend obligatoire les méthodes pour promouvoir la
sensibilisation à la sécurité. On a standardisé l'identification des
utilisateurs, leur authentification, et leurs droits d'accès. On poursuit la
certification des personnels responsables de l’audit et de la gestion de la
sécurité. Les tests de sécurité utilisent un processus standardisé et
formalisé qui conduit à des améliorations des niveaux de sécurité. Les
processus de sécurité des SI sont coordonnés avec la fonction de sécurité
générale de l'entreprise. Les rapports sur la sécurité informatique sont liés
aux objectifs métiers. La formation à la sécurité est suivie à la fois par le
personnel informatique et par le personnel des métiers. La formation à la
sécurité est planifiée et gérée de façon à répondre aux besoins des métiers
et aux profils de risques définis pour la sécurité. On a défini des objectifs et
des métriques de gestion de la sécurité mais on ne les évalue pas encore.

36
Niveau 5 Optimisé: La sécurité des SI est sous la responsabilité conjointe des responsables
métiers et informatique, et elle fait partie des objectifs de sécurité de l'entreprise. Les
exigences de sécurité informatique sont clairement définies, optimisées, et incluses
dans un plan de sécurité approuvé. Les utilisateurs et les clients sont de plus en plus
responsables de la définition des exigences de sécurité, et les fonctions de sécurité
sont intégrées aux applications dès la conception. On traite rapidement les incidents
de sécurité à l’aide de procédures spécifiques formalisées qui s’appuient sur des outils
informatiques. Des évaluations périodiques de la sécurité permettent d’évaluer le bon
fonctionnement du plan de sécurité. On collecte et on analyse systématiquement les
informations sur les menaces et sur les failles de sécurité. On communique et on met
rapidement en place des contrôles adaptés pour réduire les risques. L'amélioration
permanente des processus s'appuie sur des tests de sécurité, une analyse causale des
incidents de sécurité, et une identification proactive des risques. Les processus et
technologies de sécurité sont intégrés dans l'ensemble de l'entreprise. On évalue, on
recueille les métriques de la gestion de la sécurité et on en communique le résultat. Le
management en utilise les résultats pour adapter le plan de sécurité selon un
processus d’amélioration continue.

37
 Le modèle de maturité se base donc sur le principe suivant :

La qualité d'un système est largement tributaire de la qualité du processus utilisé pour son développement (et
sa maintenance)

Un processus immature est improvisé et chaotique. Il est caractérisé par :

 une imprévisibilité des coûts et de la qualité;

 une gestion par crise ;
 des succès grâce aux «héros», en dépit des processus

Cela occasionne des impacts importants dont :

 Perte de temps ;
 Stress et burn-out ;
 Technologie mal exploitée ;
 Contribution faible aux objectifs d’affaires.

38