la charte informatique.
Recherche et mise en place d’une alternative : dans un second temps, le RSSI
cherchera une alternative au service spontané. Cette phase est très importante et
nécessite de la part du RSSI une véritable réactivité. Si le service existe déjà dans le
catalogue de la DSI, il lui suffira de le proposer, en s’impliquant personnellement dans
la mise en œuvre. En revanche, si le service alternatif n’est pas encore fourni par la
DSI, le RSSI devra être capable de construire rapidement une solution. S’il veut que
son alternative soit acceptée par l’utilisateur, il est capital que ce que le RSSI propose
soit à la fois iso-fonctionnel et iso-ergonomique.
Blocage de l’infrastructure spontanée : ce n’est qu’une fois l’alternative en place et
acceptée que l’on pourra déposer ou bloquer l’infrastructure spontanée.
Paradoxalement, traiter de cette façon les infrastructures spontanées permet de retourner
la situation. La découverte d’une infrastructure spontanée qui, initialement, devait être
une source de conflit entre le RSSI et les services, se transforme en opportunité de
collaboration entre les deux parties.
Cette façon de travailler donne du RSSI l’image d’un collaborateur avec lequel on peut
parler, même du plus inavouable en matière de sécurité des SI. C’est à cette condition
que les infrastructures spontanées seront, sinon éradiquées, du moins considérablement
limitées.
Un dernier levier que le RSSI peut actionner est la responsabilisation personnelle de
l’utilisateur. Il est toujours utile de rappeler aux utilisateurs que lorsqu’ils installent une
infrastructure spontanée, ils font courir un risque à l’entreprise. Ils sont donc
responsables des conséquences d’un éventuel accident de leur fait.
Exemple
Voici le discours que l’on peut tenir auprès d’un utilisateur utilisant un service de partage des fichiers sur le
cloud : « Est-ce qu’il vous est déjà arrivé de passer spontanément un contrat au nom de l’entreprise
auprès d’un fournisseur, sans en avoir informé votre hiérarchie ? » Dans la plupart des cas, la réponse
logique à la question est non. La réplique du RSSI peut donc être : « Pourtant, en acceptant les CGU,
vous engagez votre entreprise auprès d’un fournisseur sans en informer votre hiérarchie. Pourquoi ce que
vous vous interdisez d’un côté vous l’autorisez-vous de l’autre ? »
Ajoutons que par nature (et à juste titre), les chefs de projet informatique se perçoivent
comme des bâtisseurs de solutions, créant des applications et des infrastructures aidant à
résoudre des problèmes ou à créer de la valeur. D’une façon caricaturale, leur devise
pourrait être : « Un problème ? Une solution ! ». Cette catégorie de personnel n’est donc
pas habituée à se poser la question suivante : « En quoi la solution que je vais mettre en
place met-elle en péril mon entreprise ? » Le RSSI doit les aider à se poser cette
question, surtout lorsqu’ils s’apprêtent à mettre en place une infrastructure spontanée.
Recherche et mise en place d’une alternative : dans un second temps, le RSSI
cherchera une alternative au service spontané. Cette phase est très importante et
nécessite de la part du RSSI une véritable réactivité. Si le service existe déjà dans le
catalogue de la DSI, il lui suffira de le proposer, en s’impliquant personnellement dans
la mise en œuvre. En revanche, si le service alternatif n’est pas encore fourni par la
DSI, le RSSI devra être capable de construire rapidement une solution. S’il veut que
son alternative soit acceptée par l’utilisateur, il est capital que ce que le RSSI propose
soit à la fois iso-fonctionnel et iso-ergonomique.
Blocage de l’infrastructure spontanée : ce n’est qu’une fois l’alternative en place et
acceptée que l’on pourra déposer ou bloquer l’infrastructure spontanée.
Paradoxalement, traiter de cette façon les infrastructures spontanées permet de retourner
la situation. La découverte d’une infrastructure spontanée qui, initialement, devait être
une source de conflit entre le RSSI et les services, se transforme en opportunité de
collaboration entre les deux parties.
Cette façon de travailler donne du RSSI l’image d’un collaborateur avec lequel on peut
parler, même du plus inavouable en matière de sécurité des SI. C’est à cette condition
que les infrastructures spontanées seront, sinon éradiquées, du moins considérablement
limitées.
Un dernier levier que le RSSI peut actionner est la responsabilisation personnelle de
l’utilisateur. Il est toujours utile de rappeler aux utilisateurs que lorsqu’ils installent une
infrastructure spontanée, ils font courir un risque à l’entreprise. Ils sont donc
responsables des conséquences d’un éventuel accident de leur fait.
Exemple
Voici le discours que l’on peut tenir auprès d’un utilisateur utilisant un service de partage des fichiers sur le
cloud : « Est-ce qu’il vous est déjà arrivé de passer spontanément un contrat au nom de l’entreprise
auprès d’un fournisseur, sans en avoir informé votre hiérarchie ? » Dans la plupart des cas, la réponse
logique à la question est non. La réplique du RSSI peut donc être : « Pourtant, en acceptant les CGU,
vous engagez votre entreprise auprès d’un fournisseur sans en informer votre hiérarchie. Pourquoi ce que
vous vous interdisez d’un côté vous l’autorisez-vous de l’autre ? »
Ajoutons que par nature (et à juste titre), les chefs de projet informatique se perçoivent
comme des bâtisseurs de solutions, créant des applications et des infrastructures aidant à
résoudre des problèmes ou à créer de la valeur. D’une façon caricaturale, leur devise
pourrait être : « Un problème ? Une solution ! ». Cette catégorie de personnel n’est donc
pas habituée à se poser la question suivante : « En quoi la solution que je vais mettre en
place met-elle en péril mon entreprise ? » Le RSSI doit les aider à se poser cette
question, surtout lorsqu’ils s’apprêtent à mettre en place une infrastructure spontanée.