Publicité en cours de chargement...
ITIL v3 et le catalogue des services en sécurité SI – partie 1
Intéressons-nous plus particulièrement au volet « disponibilité » de l'offre de service SI. Ce n'est bien entendu pas le seul aspect (il y a tout le DICP), mais la partie disponibilité est la plus simple à formaliser sous l'aspect d'un catalogue de service (SLA).
La première étape est de définir la liste des composants du SI qui sont officiellement identifiés comme critiques : ce qui est inclus dans la liste bénéficie d'un traitement particulier, ce qui n'y est pas est en mode best effort en termes de délais de remise en service. Cela sert notamment à officialiser ce qui est d'astreinte ou pas : les informaticiens d'astreinte disposent d'un document sur lequel se baser (qui n'a pas été écrit par eux, du reste) et qui les autorise à refuser de traiter un appel concernant un composant absent de la liste.
La deuxième étape est de positionner un niveau de criticité pour chacun des éléments de la liste. Dans l'idéal, on définit trois niveaux de criticité standard (par exemple GOLD, SILVER et BRONZE) comportant chacun un engagement en termes de délai de remise en service. Par exemple 4h pour les composants en GOLD, 12h pour le SILVER et 48h pour le BRONZE. Il est possible d'affiner le modèle en distinguant les délais de remise en service pour les arrêts en heures ouvrables ou non ouvrables, de définir un quatrième niveau de service, etc.
La troisième étape est de positionner des responsables identifiés, à la fois côté DSI et côté MOA, pour chacun des composants listés. Quand l'un des éléments tombe en panne, qui prévenir en effet côté MOA ? Qui prend en charge côté DSI, à la fois sur le plan technique (système) et fonctionnel (AMOA) ?
La quatrième étape est de définir, pour chaque élément de la liste, au moins deux périodes temporelles pour les arrêts programmés de maintenance : une période pour les arrêts courts (moins de 30mn) qui doit obligatoirement se positionner en heures et jours ouvrables, une période pour les arrêts longs (plus de 30mn), qui doit se positionner hors heures ouvrables. On pourra également renseigner des conditions de déclenchement (par exemple avertir la MOA 1 semaine à l'avance avec un rappel à J-1). Cette formalisation permet de ne pas se reposer indéfiniment la question des arrêts, et de renégocier à chaque fois.
Avec cela, on est parés : bien entendu, à chaque nouvel ajout de composant, à chaque incident il convient de se poser la question de savoir si les éléments renseignés sont juste ou s'il faut les remettre à jour.
Avez-vous apprécié ce contenu ?
A lire également.

Ce qu’il fallait retenir de l’édition 2025 du congrès APSSIS
01 juil. 2025 - 00:00,
Actualité
- DSIHLa 13ᵉ édition du congrès APSSIS, qui s’est tenue en juin 2025, a une nouvelle fois confirmé sa place centrale dans l’écosystème de la cybersécurité en santé. Au fil de trois jours de conférences, de débats et de rencontres, RSSI, DPO, DSI, juristes et institutionnels ont croisé leurs expertises pou...

Le 8ème opus des guides cyber-résilience de l’APSSIS est en ligne !
30 juin 2025 - 20:50,
Communiqué
- APSSISL’APSSIS a le plaisir d’annoncer la publication du 8ème opus des Guides Cyber-résilience à destination des professionnels du secteur. Conçus et élaborés par Cédric Cartau, ces guides se veulent à la fois accessibles, techniques et pratiques.
La cyber et les sacs de luxe
30 juin 2025 - 20:44,
Tribune
-C’est la fin du premier semestre, il est temps de faire un bilan à mi-course de l’année 2025. Et il s’en est passé, des choses, pas forcément douces et roses.

En direct du congrès APSSIS 2025 –– conférence sur l’histoire des malwares
24 juin 2025 - 18:00,
Tribune
-Temps fort traditionnel, Michel Dubois nous a habitués à des conférences techniques sur des sujets pointus, telle l’histoire du chiffrement. Nous voilà donc embarqués dans l’histoire des malwares, et on part de loin : machine de Turing, théorie de l’informatique de la fin de la Seconde Guerre mondia...