5.1.4.2. La confusion entre les causes et les
effets
Au delà de la gestion des incidents, la gestion du
risque opérationnel est un sujet difficile. La confusion entre les
causes (fait générateur) et les effets (évènement
perçus et impact) relève d'une incompréhension grave de la
démarche et des objectifs poursuivis par les régulateurs. Une
véritable gestion de risque ne peut se permettre d'ignorer l'importance
de la recherche des causes profondes et endémiques qui créent les
potentialités d'incidents ou leur caractère récurrent. La
transparence et la vérité sont ici les conditions
nécessaires à remplir si l'on veut progresser au delà de
la seule gestion des incidents.
La recherche des vraies causes est un comportement nettement
plus responsable et efficace qu'une simple alimentation du reporting
légal aux régulateurs. Les équipes de production doivent
avoir la volonté de travailler sur les causes endémiques des
incidents après leur analyse. Quelle est la vraie cause d'un incident
faisant suite à l'utilisation de fichiers réels pour effectuer
des tests ? On peut se rabattre sur une erreur humaine, mais de la part de qui
au premier niveau ? N'y a-t-il pas une vraie cause qui est que quelqu'un a
autorisé le travail de fichiers réels en tests ? Mais ce niveau
de détail, qui correspond à la vraie vie, ne figure pas sur la
liste de Bale II.
Deux cas de figure peuvent se présenter pour la saisie
dans les IDB :
Un seul couple : évènement-cause ;
Plusieurs incidents liés, pour lesquels se constitue une
chaine d'évènement causes-cascade.
Si par exemple, l'incident initial est une défaillance
informatique qui entraine un incident au niveau de métier, celui-ci dira
que la cause est informatique. Mais l'informatique peut détecter
après diagnostic que c'est l'utilisateur qui fait planter non seulement
sa propre application, mais celles d'autres utilisateurs en aval.
Dans tous les cas, il faut veiller à ce que tous les
interlocuteurs concernés, notamment les personnes à l'origine des
incidents liés puissent avoir accès aux données utiles, ce
qui peut poser des problèmes de confidentialité. Cela signifie
qu'ils doivent être désignés comme intervenants en tant que
validateurs d'une entité impactée ou concernée.
Dans le cas général, il est
préférable de ne saisir qu'un seul incident racine, celui qui
représente l'impact essentiel sur l'activité. Les autres
conséquences seront incluses dans la description de l' incident racine
et prises en compte dans l'évaluation de l'impact financier.
Les circuits existants en matière de gestion des
incidents informatiques jouent un rôle essentiel dans la
déclaration des incidents opérationnels, l'exhaustivité de
la collecte et la qualité des données recueillies.
| 
