Traitement des demandes
Si les demandes non programmées se multiplient, le RSSI aura tendance à ne pas les
traiter correctement. Nous verrons comment il peut s’organiser, puis nous aborderons
ensuite l’importance d’être réactif dans ce domaine et comment prioriser les traitements.
Comment gérer le tout-venant ?
Nous avons vu que le tout-venant interrompt le RSSI dans son travail et le contraint à se
réorganiser pour servir ces demandes non programmées. Il est possible de limiter ce
désagrément en jouant sur deux leviers.
Le premier levier consiste tout simplement à provisionner du temps pour traiter ces
demandes. Même si la nature chaotique du tout-venant rend les prévisions difficiles, le
temps à provisionner est fonction de la charge moyenne consacrée à traiter ces demandes.
Par exemple, si dans les six derniers mois, les demandes non programmées ont occupé le
RSSI environ dix jours, le RSSI pourra bloquer une demi-journée par semaine. En
somme, il s’agit de tenir compte, de façon prévisionnelle, des demandes qui ne
manqueront pas d’arriver.
Le second levier consiste à établir au maximum des procédures pour les demandes
récurrentes. L’idée est de profiter du traitement de la demande pour la formaliser par écrit
en précisant bien qui doit faire quoi, puis de faire connaître la procédure aux différentes
parties concernées. Ainsi, si une demande similaire se présente à nouveau, il suffit de
dérouler la procédure. Cette façon de faire libère grandement le RSSI et améliore
sensiblement les temps de réponse aux demandes.
Les demandes récurrentes les plus communes et pour lesquelles il est facile d’écrire une
procédure sont les suivantes :
demande d’ouverture de compte de la part d’un utilisateur ;
demande de création de droits de la part d’un utilisateur ;
demande d’ouverture de flux réseau par un chef de projet ou par la production.
Il est entendu que la gestion de comptes ainsi que la gestion de droits doivent
normalement déjà faire l’objet de procédures bien cadrées. Cependant, les cas n’entrant
pas exactement dans la procédure sont souvent envoyés au RSSI. Il est donc intéressant
que, chaque fois qu’il est sollicité, le RSSI analyse ces exceptions et fixe des critères de
décision qui seront ensuite intégrés dans les procédures existantes.
Pour ce qui est des demandes des chefs de projet et des architectes, l’idéal est de créer un
comité qui se réunit périodiquement (la période étant fonction du flux des demandes)
pour prendre connaissance, discuter puis décider de solutions. Naturellement, si un
comité d’architecture ou des comités projet existent déjà, il n’est pas utile d’en créer un
autre juste pour la sécurité. Il suffit au RSSI de se faire inviter aux comités pertinents.
Même les incidents, qui par nature sont imprévisibles, peuvent faire l’objet de
procédures. En effet, certains incidents comme les attaques virales ou les attaques visant
Si les demandes non programmées se multiplient, le RSSI aura tendance à ne pas les
traiter correctement. Nous verrons comment il peut s’organiser, puis nous aborderons
ensuite l’importance d’être réactif dans ce domaine et comment prioriser les traitements.
Comment gérer le tout-venant ?
Nous avons vu que le tout-venant interrompt le RSSI dans son travail et le contraint à se
réorganiser pour servir ces demandes non programmées. Il est possible de limiter ce
désagrément en jouant sur deux leviers.
Le premier levier consiste tout simplement à provisionner du temps pour traiter ces
demandes. Même si la nature chaotique du tout-venant rend les prévisions difficiles, le
temps à provisionner est fonction de la charge moyenne consacrée à traiter ces demandes.
Par exemple, si dans les six derniers mois, les demandes non programmées ont occupé le
RSSI environ dix jours, le RSSI pourra bloquer une demi-journée par semaine. En
somme, il s’agit de tenir compte, de façon prévisionnelle, des demandes qui ne
manqueront pas d’arriver.
Le second levier consiste à établir au maximum des procédures pour les demandes
récurrentes. L’idée est de profiter du traitement de la demande pour la formaliser par écrit
en précisant bien qui doit faire quoi, puis de faire connaître la procédure aux différentes
parties concernées. Ainsi, si une demande similaire se présente à nouveau, il suffit de
dérouler la procédure. Cette façon de faire libère grandement le RSSI et améliore
sensiblement les temps de réponse aux demandes.
Les demandes récurrentes les plus communes et pour lesquelles il est facile d’écrire une
procédure sont les suivantes :
demande d’ouverture de compte de la part d’un utilisateur ;
demande de création de droits de la part d’un utilisateur ;
demande d’ouverture de flux réseau par un chef de projet ou par la production.
Il est entendu que la gestion de comptes ainsi que la gestion de droits doivent
normalement déjà faire l’objet de procédures bien cadrées. Cependant, les cas n’entrant
pas exactement dans la procédure sont souvent envoyés au RSSI. Il est donc intéressant
que, chaque fois qu’il est sollicité, le RSSI analyse ces exceptions et fixe des critères de
décision qui seront ensuite intégrés dans les procédures existantes.
Pour ce qui est des demandes des chefs de projet et des architectes, l’idéal est de créer un
comité qui se réunit périodiquement (la période étant fonction du flux des demandes)
pour prendre connaissance, discuter puis décider de solutions. Naturellement, si un
comité d’architecture ou des comités projet existent déjà, il n’est pas utile d’en créer un
autre juste pour la sécurité. Il suffit au RSSI de se faire inviter aux comités pertinents.
Même les incidents, qui par nature sont imprévisibles, peuvent faire l’objet de
procédures. En effet, certains incidents comme les attaques virales ou les attaques visant