les boîtes aux lettres des utilisateurs sont très fréquents. Si elle ne décharge pas le RSSI
de gérer les incidents, la rédaction de fiches réflexes contribue grandement à le soulager,
en répartissant les rôles et responsabilités. De cette façon, dès qu’un incident similaire
survient, chacun sait ce qu’il a à faire, déchargeant ainsi le RSSI. Un chapitre consacré à
la gestion des incidents détaille les fiches d’incidents.
En somme, c’est quasiment l’ensemble du tout-venant qui peut être intégré dans des
procédures bien définies. Dans ce domaine, le mot d’ordre du RSSI est double :
intégrer autant que possible le tout-venant dans les processus existants ;
intégrer le reste en tant qu’actions gérées, avec un suivi dans les instances appropriées
(comité de sécurité, comité de suivi, etc.).
Importance de gérer le tout-venant
Le traitement du tout-venant est à la fois un risque et une opportunité. Il peut être un
risque car s’il n’est pas sérieusement pris en compte par le RSSI, cela générera un réel
mécontentement de la part des utilisateurs, qui se traduira par trois conséquences
directes.
Contournement : un utilisateur sentant que sa demande n’a pas été prise en compte
sérieusement ou dans un délai trop long trouvera mécaniquement une alternative pour
résoudre son problème en contournant le RSSI et la DSI.
Non-sollicitation : non seulement le demandeur déçu sera tenté de contourner le RSSI
pour sa demande, mais il ne le consultera plus à l’avenir.
Incitation au contournement : enfin, l’utilisateur ne manquera pas d’inciter son
entourage à ne pas solliciter le RSSI, vu sa piètre réactivité.
À l’inverse, si le RSSI se montre très réactif face à ces demandes, il encouragera les
utilisateurs à travailler avec lui. Ils n’hésiteront pas à relayer à leur entourage les bonnes
relations de travail que l’on peut établir avec le RSSI. Le responsable sécurité se
positionne ainsi comme un cadre au service des autres et apporteur de solutions, c’est-àdire à l’opposé de l’image que les utilisateurs ont de lui spontanément.
Notons que le chapitre consacré à la sensibilisation dans cet ouvrage nous dit que le RSSI
doit entreprendre régulièrement des actions de sensibilisation à la sécurité au sein de
l’entreprise. Or, dans les jours qui suivent chaque sensibilisation, il est très fréquent que
des utilisateurs « jouant le jeu » viennent consulter le RSSI pour telle ou telle demande.
Bien recevoir ces utilisateurs et traiter leur demande en priorité est très important pour
les raisons exposées précédemment. En somme, il est capital de ne pas décevoir.
Priorités
Nous avons vu plus haut qu’un des critères pour prioriser une demande non programmée
est de tenir compte du demandeur. Cela peut paraître étrange par rapport aux autres
critères tels que l’urgence ou l’importance.
Il n’est pourtant pas faux que certaines demandes, issues de certaines populations, ont
intérêt à être traitées rapidement. Voici quelques cas significatifs.
de gérer les incidents, la rédaction de fiches réflexes contribue grandement à le soulager,
en répartissant les rôles et responsabilités. De cette façon, dès qu’un incident similaire
survient, chacun sait ce qu’il a à faire, déchargeant ainsi le RSSI. Un chapitre consacré à
la gestion des incidents détaille les fiches d’incidents.
En somme, c’est quasiment l’ensemble du tout-venant qui peut être intégré dans des
procédures bien définies. Dans ce domaine, le mot d’ordre du RSSI est double :
intégrer autant que possible le tout-venant dans les processus existants ;
intégrer le reste en tant qu’actions gérées, avec un suivi dans les instances appropriées
(comité de sécurité, comité de suivi, etc.).
Importance de gérer le tout-venant
Le traitement du tout-venant est à la fois un risque et une opportunité. Il peut être un
risque car s’il n’est pas sérieusement pris en compte par le RSSI, cela générera un réel
mécontentement de la part des utilisateurs, qui se traduira par trois conséquences
directes.
Contournement : un utilisateur sentant que sa demande n’a pas été prise en compte
sérieusement ou dans un délai trop long trouvera mécaniquement une alternative pour
résoudre son problème en contournant le RSSI et la DSI.
Non-sollicitation : non seulement le demandeur déçu sera tenté de contourner le RSSI
pour sa demande, mais il ne le consultera plus à l’avenir.
Incitation au contournement : enfin, l’utilisateur ne manquera pas d’inciter son
entourage à ne pas solliciter le RSSI, vu sa piètre réactivité.
À l’inverse, si le RSSI se montre très réactif face à ces demandes, il encouragera les
utilisateurs à travailler avec lui. Ils n’hésiteront pas à relayer à leur entourage les bonnes
relations de travail que l’on peut établir avec le RSSI. Le responsable sécurité se
positionne ainsi comme un cadre au service des autres et apporteur de solutions, c’est-àdire à l’opposé de l’image que les utilisateurs ont de lui spontanément.
Notons que le chapitre consacré à la sensibilisation dans cet ouvrage nous dit que le RSSI
doit entreprendre régulièrement des actions de sensibilisation à la sécurité au sein de
l’entreprise. Or, dans les jours qui suivent chaque sensibilisation, il est très fréquent que
des utilisateurs « jouant le jeu » viennent consulter le RSSI pour telle ou telle demande.
Bien recevoir ces utilisateurs et traiter leur demande en priorité est très important pour
les raisons exposées précédemment. En somme, il est capital de ne pas décevoir.
Priorités
Nous avons vu plus haut qu’un des critères pour prioriser une demande non programmée
est de tenir compte du demandeur. Cela peut paraître étrange par rapport aux autres
critères tels que l’urgence ou l’importance.
Il n’est pourtant pas faux que certaines demandes, issues de certaines populations, ont
intérêt à être traitées rapidement. Voici quelques cas significatifs.