5.1.4. Gestion des incidents informatiques
5.1.4. 1.Causes - événements -
impacts
Il est fondamental de voir en quoi les incidents
avérés saisis dans une base IDB peuvent servir à
améliorer la gestion des risques opérationnels. La bonne gestion
du risque opérationnel suppose en effet d'avoir à la fois une
vision précise des relations « évènement causes
impacts » et une capacité d'agir sur les causes. Il faut donc se
demander si le rattachement aux nomenclatures d'évènements et de
causes définies par le régulateur, d'une part et l'organisation
du dispositif mis en place par Direction, d'autre part, offrent une
efficacité permettant de réduire les risques au quotidien.
Tant à la direction informatique que dans les
métiers et autres fonctions, des systèmes de
gestion
d'incidents existent déjà et sont parfois
spécialisés selon les processus concernés. Mais
c'est
à partir d`IDB, alimenté depuis 2002 avec plus ou moins de
bonheur par les entités, que la
direction des risques prépare le reporting et soumet
l'analyse des incidents saisis au comité du risque
opérationnel.
Le nombre de possibilités de rangement offertes par les
nomenclatures de Bale II pour les incidents de type informatique est
très limité, l'information sur les incidents étant
complétée la plupart du temps en texte libre, ce qui rend
difficiles les analyses a posteriori. De plus, le taux de saisie des incidents
d'origine informatique par les métiers est assez faible, y compris pour
la Direction informatique par rapport à ses propres risques.
La méthode AMA va conduire, par l'analyse des processus
et des scénarios de risques, à une nomenclature plus
précise des types d'évènements et de causes
rattachés à des rubriques standards de Bale II, mais
différentes de celles de l'IDB actuelle. Il va falloir faire converger
et mapper les nomenclatures d'évènements et de causes pour IDB et
pour AMA. Mais dans les deux cas, les nomenclatures proposées sont trop
éloignées du réel perçu sur le terrain. Il faudrait
définir des types d'évènements et de causes plus
réalistes, vraisemblablement entre 50 et 100 dans chaque cas, et les
rattacher systématiquement aux rubriques de Bale II, si l'on veut
être en mesure d'effectuer des analyses pertinentes et pas seulement de
beaux rapports pour régulateur. Les analyses réalisées
avec AMA, qui font entrer en ligne de compte les pertes non prévues,
doivent également mettre en évidence des indicateurs clés
de risques et des indicateurs de maitrise du risque qui rentreront dans les
formules de calcul du capital. Il est impératif de savoir si la base IDB
est un outil de gestion opérationnelle du risque ou un simple instrument
de reporting vers les régulateurs.
L'analyse du contenu de la base IDB et des procédures
de gestion des incidents informatiques part du constat que seuls deux
évènements et deux causes étaient proposés par Bale
II pour qualifier les incidents. Dans ce cadre, la DI doit fournir sa propre
liste d'évènements, en précisant bien que la typologie des
causes, plus difficile à établir, viendra après une
analyse en profondeur des bases d'incidents utilisées par les
équipes de production.
Dans l'état actuel des choses, on a le choix entre
plusieurs classifications des risques dans le processus DVT :
Les deux nomenclatures issues de Bale 2, différents entre
les évènements constatés (IDB) et les
évènements potentiels(AMA) ;
Le mapping de ces différentes listes est
ingérable à la main. Elles sont difficilement réductibles,
car leurs critères de classement font apparaitre de dépendances
multi évaluées. Par exemple, les risques projets liés a la
qualité des relations MOA /MOE sont croisés avec d'autres
thèmes en fonction de l'étape du projet (spécifications,
recette, mise en oeuvre). L'examen des causes
issues de la vraie vie et de l'expérience quotidienne
des chefs de projets montre que, sur quatre principales causes relevées
par les chefs de projets, la défaillance du système de
qualité apparait sur la liste du niveau 3 proposé par Bale II.
Pour compliquer l'affaire ou telle nomenclature
spécifique peux venir s'ajouter dans le paysage. Il est naturel que des
nomenclatures spécifiques soient nécessaires pour des processus
techniques ou pour des fonctions comme RH, achat, déontologie, audit,
budget.
Dans ces conditions de flous artistiques sur les nomenclatures
d'évènement et de cause, et en l'absence d'un
référenciel pour les processus communautaires, il est très
difficile pour les métiers d'intégrer les processus des fonctions
dans leur propre processus.
La typologie d'évènement définit par bale
II est très éloigné de la pratique quotidienne vécu
par les équipes. Le niveau de granularité des nomenclatures
offertes n'est pas suffisamment proche du vécu de l'utilisateur, ce qui
lui fait hésiter entre plusieurs événements possible.
Il est clair qu'il faudrait créer un niveau 4 pour
assurer l'intégration, la cohérence et la
traçabilité globale entre la gestion des incidents et la gestion
des risques. Le problème des incidents récurrents doit aussi
être résolu. La recherche des causes et leur remonté vers
les personnes qui en ont la responsabilité et les moyens de correction
constitue le noeud de l'affaire.
Plutôt que d'embrouiller les choses en laissant
l'utilisateur rechercher une autre cause approximative, il vaut mieux lui
fournir une bonne liste d`événements directement
compréhensible, et passé la main aux spécialistes du
problème pour qu'ils renseignent les vraies causes après
diagnostic et correction.
Il est fondamental que l'on puisse revenir sur les causes
après la saisie initiale de l'incident effectuée le plus souvent
par l'utilisateur du métier concerné.
Si le dispositif existant de gestion des incidents informatiques
n'est pas intégré par
l'alimentation de la base IDB :
- les reportings effectués ne sont pas cohérents,
les impacts économiques et financiers
sont peux fiables et la traçabilité globale doit
être faite à la main ;
- Les circuits d'information sont multiples entre la gestion des
incidents et la gestion du risque opérationnel.
- Les liens de rattachement dans le cas ou un incident global
crée de multiples incidents locaux ne sont pas gérés
automatiquement.
Il faut améliorer la qualité de la saisie des
incidents, renforcer les contrôles de cohérence,
utiliser une
nomenclature et un vocabulaire plus exigeants qui permettent de repérer
les
doublons et les conséquences multiples d'un même
évènement, de détecter les corrélations
d'évènements, les évènements récurrents, les
propagations, les faux incidents, les alertes.
La recherche des causes n'est pas à faire par les
utilisateurs qui constatent un évènement ou en subissent les
impacts mais par les professionnels de l'informatique, seuls capables
d'apporter des actions correctives et préventives, ceci souvent
après une recherche approfondie et longue. Les équipes de
production et de support de la DI possèdent dans la plupart des cas
l'essentiel des informations, à l'exception des impacts financiers qui
sont connus des métiers. Dans tous les cas, la mise en relation entre
l'informatique et les métiers est indispensable pour que toute
l'information nécessaire à la collecte de l'incident dans IDB
soit recueillie. L'élaboration de la liste des causes demande donc qu'un
travail préalable soit effectué en liaison avec les
équipes du terrain (la production).
La faiblesse de la démarche AMA, c'est de lancer les
métiers dans leurs analyses de risques potentiels indépendamment
de l'analyse des historiques d'incidents de la base IDB. Au plan de
l'organisation, une dichotomie préjudiciable est créée
artificiellement entre la gestion des incidents et la gestion des risques
opérationnels, comme si les analyses de risques faites dans la
précipitation et l'enthousiasme du début ne devaient pas survivre
dans un mode de fonctionnement opérationnel. C'est une fuite en avant
irrationnel et opportuniste, car il sera difficile de greffer et
d'intégrer après coup le réseau d'analyses du risque
opérationnel dans les circuits d'incidents.
| 
