MCG et le Service Level Agreement (SLA): une notion floue, mais pourtant un service très important !

Au cœur du processus d’une bonne stratégie Cyber, il y a tous les aspects liés à la maintenance et à la partie Helpdesk. Veiller au jour le jour que tous vos assets sont bien protégés et savoir comment agir en cas de pépins, c’est ça aussi la force des équipes de MCG - Matias Consulting Group.

Historiquement (et dans certaines organisations c’est encore le cas), le Service IT est le service « mal aimé » de tous les autres services. Nous avons déjà discuté de cela dans plusieurs articles.

Nous pouvons trouver plusieurs raisons qui peuvent être  à l’origine de cette situation :

1. Souvent, on ne fait appel au service IT que quand cela ne fonctionne pas ou en pleine crise, la frustration et le stress sont donc à leur apogée
    
2. Le service IT, souvent consulté en dernière étape, se voit souvent contraint de déployer (ou d’intégrer) des applicatifs métier pour lesquels il n’a pas pu donner son avis stratégique en amont. Le service  IT est alors perçu comme réticent.
    
3. Tout le travail réalisé par les services IT, infrastructures IT, Cybersécurité sont souvent la partie immergée de l’iceberg. C’est peu visible, et donc on n’y voit peu de valeur. 
    

La pertinence d’un SLA: des attentes à l’importance du niveau de disponibilité 
 

La mise en place d’un contrat Service Level Agreement ou SLA demande d’être très clair sur les attentes dès le début de la relation.

Pour éviter des frustrations et discussions de toute part, notamment entre le service IT et les autres services de l’entreprise, il faut être très descriptif sur ce qui est attendu. Pour rappel, la notion de SLA est apparue dans les années 80 et plus particulièrement dans le domaine des télécommunications.

Au niveau de la définition - un SLA, ou Service Level Agreement, est un accord passé entre le service IT (offreur) et le reste de l’organisation (services demandeurs/consommateurs) définissant la « qualité du service » attendue. 

Cette qualité de service attendue, et souvent définie par des indicateurs de performance ou KPIs en anglais (Key Performance Indicators), qui peuvent revêtir différentes formes mais qui doivent en règle générale être des objectifs SMART – c’est à dire, des éléments de mesure tangibles qui seront spécifiques, mesurables, acceptables, réalistes et relevants, basés sur une période de temps définie.

Il y aura donc discussion et arbitrage sur la qualification et la définition de ces indicateurs, de communs accords entre les parties, de toute bonne foi (car il y aura toujours une certaine part de subjectivité), et en fonction des ressources octroyées à ce même service IT, pour mettre en place ce SLA

Voilà pour la définition, certes un peu théorique, où il apparaît de manière évidente que de la définition précise « du service attendu » et donc des KPIs (key performance indicators) sous-jacents qui en découlent, dépend la totalité de la pertinence de ces SLAs.

Service Level Agreement (SLA) et Cybersécurité: atteindre une disponibilité réaliste 
 

En Cybersécurité, c’est encore plus complexe. Dans le cadre des objectifs primaires à atteindre (aussi appelés vecteur de risque CIA/CID) on doit parler du « niveau de disponibilité » (availability pour les anglophones). 

Ceci est un bon exemple pour expliquer la difficulté de définir un KPI réaliste et avec précision. 

Déjà partons du principe que nous parlons d'un taux, et ce taux est exprimé en %. Ce taux est donc calculé par la formule suivante :

MTTF/ (MTTF + MTTR) où MTTF = est le temps moyen de bon fonctionnement jusqu'à la première panne et MTTR = est le temps moyen jusqu'à réparation.

C’est ainsi qu’on définit la règle des X 9 … 99.9%, 99.99%, 99.999 % …

Prenons par exemple le 99.99 %, il signifie 0.01% de temps d’indisponibilité, soit un peu plus de 52 minutes de temps d’arrêt par an.
Et c’est là que commence le problème de la définition de cet indicateur de performance.
 

Fenêtre de disponibilité: soyons réalistes et objectifs 

Car pour ce calcul de la performance de disponibilité, il y a une hypothèse sous-jacente très forte qui est que la fenêtre de disponibilité doit être est de 24h/24h et de 7j/7j. C'est-à- dire une dévotion totale, corps et âme.

Le problème est que nous sommes en Belgique.

La majorité des entreprises, PMEs et TPEs, dorment la nuit et leur personnel ne travaille pas le week-end. Nous connaissons tous des exceptions (d’ailleurs de plus en plus nombreuses) à cette règle, mais les organisations syndicales vous rappelleront vite à l’ordre par rapport au respect de la législation sociale.

De ce fait, de nouveau dire qu’il faut atteindre « un niveau de disponibilité » n’est pas suffisant, car la disponibilité doit être définie et relativisée clairement par rapport aux réalités du terrain.

Éléments clés à définir: est-ce l’accès aux données ou à une ressource précise ? Parlons-nous d’une fonctionnalité particulière ou d’une application ? Afin d’avoir une relation fluide et satisfaisante,   il est donc important de bien définir ce qui est attendu.

Par rapport à ce KPI en particulier, il est aussi important qu’il soit « réaliste ». En effet, dans le calcul de ce KPI, les mécanismes de redondance, les contrats de support sous-jacents et la disponibilité des ressources humaines pour intervenir au plus vite en cas de panne (d’indisponibilité des systèmes) doivent tous être alignés. 

Redondance instantanée des composantes de sécurité et temps de rétablissement des systèmes…
 

Prenons un exemple typique rencontré en cybersécurité dans de nombreuses sociétés.

Le client souhaite avoir une redondance instantanée des composantes sécurisant l’accès à Internet (par exemple: firewalls en cluster), mais le TTR (ou Temps de Rétablissement de la ligne internet) est lui de 4 ou 8 heures. Vous voyez l’incohérence ? 

Pour conclure, il faut aussi couper court aux mythes et aux rêves les plus fous.

Microsoft, qui est un des plus gros fournisseurs d’applications Cloud, définit de manière très précise ses contrats  SLA de disponibilités à l’ULR suivante :

https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services 

Si nous prenons Exchange Online, Microsoft défini que la disponibilité est basée sur l’impossibilité pour les utilisateurs d’envoyer et de recevoir des e-mails avec Outlook Web Access.

… et qu’il garantit un niveau supérieur à 99.9 %, alors que Microsoft  maîtrise toute la chaîne: les connexions internet, les datacenters, le hardware - et surtout le software, ce sont quand même ses propres applications !

Nous pouvons donc clairement affirmer que la disponibilité du Cloud est donc souvent surestimée.

Sans doute pour cela que Gartner a encore rappelé récemment les 9 principes de la résilience des services dans le Cloud:

(https://www.soluxions-magazine.com/resilience-du-cloud-9-principes/?utm_source=brevo&utm_campaign=FR%20-%20Newsletter%20ICT%20-%2005%20DECEMBRE%202023&utm_medium=email) 

MCG (Matias Consulting Group), expert en IT et en cybersécurité en Belgique (Louvain-la-Neuve, Brabant wallon) fourni et est habitué aux Service Level Agreement pour ses clients, nous avons l’expérience et l’expertise pour faire face aux cyberattaques, ainsi qu’ aux accidents IT, aux pannes digitales, etc.

Nous souhaitons toujours avoir des échanges honnêtes et transparents sur nos services, et nous ne survendons pas nos capacités. Car une relation saine, honnête et transparente est la clé du succès et de la fiabilité, pas de la superficialité. 

N’hésitez pas à nous contacter pour discuter avec nos experts:

https://www.mcg.be/fr/contact